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The  increasing  convenience  and  ubiquity  of  mobile 
computing  and  smart  personal  communication  devices 
presents  an  irresistible  target  for  malicious  actors.  The  rush  to 
provide  applications  means  few  are  tested  to  detect,  analyze, 
and  remediate  weaknesses.  Public  Wi-Fi  networks  can  also 
provide  a  vulnerable  entry  point  to  our  mobile  device  informa¬ 
tion  systems.  As  a  result,  hackers  are  able  to  quickly  exploit 
software  on  smartphones. 

The  challenge  of  securing  the  mobile  world  is  complex  and 
therefore  requires  multi-disciplinary  solutions.  The  security 
models  currently  provided  by  major  mobile  providers  are  not 
sufficient  to  meet  the  information  protection  needs  of  civil¬ 
ian  and  defense  agencies.  Application  developers,  network 
administrators,  and  incident  responders  need  to  collaborate  to 
address  mobile  computing  risk.  To  be  effective,  this  collabora¬ 
tion  requires  rapid  sharing  of  standardized  threat  and  vulner¬ 
ability  information  so  public  and  private  stakeholders  can  act 
quickly  to  mitigate  risks  to  their  operations  and  activities. 

Fortunately,  much  of  what  we  already  know  and  do  in 
cybersecurity  applies  to  the  mobile  world  and  the  challenge 
of  securing  it.  Consistency  in  the  identification  and  interpreta¬ 
tion  of  software  weaknesses,  attack  patterns,  and  malware 
data  is  essential  for  quick  and  efficient  information  sharing. 
DHS  sponsors  programs  that  help  standardize  such  data, 
thus  allowing  companies  and  organizations  to  collect,  store, 
and  define  it  in  compatible  formats.  By  promoting  common 
data  taxonomies  and  methodologies  for  storing,  indexing,  and 


interpreting  malware  samples,  DHS  is  driving  towards  seam¬ 
less  diagnosis  and  remediation  of  exploitable  software  across 
the  various  mobile  platforms.  These  are  necessary  conditions 
for  near  real-time  situational  awareness  of  vulnerabilities  and 
malware.  However,  collaboration  should  not  end  with  remedia¬ 
tion  of  malware.  DHS  envisions  an  environment  that  grants 
public  and  private  sector  owners  and  operators  of  information 
technology  systems  access  to  an  entire  range  of  security  au¬ 
tomation  tools  and  capabilities,  including  software  assurance 
education  materials  and  security-content  authoring  services. 

The  public  and  private  sectors  occupy  equally  important- 
and  equally  informed— roles  within  their  particular  area  of 
cybersecurity  expertise.  Rapid,  bidirectional  information  shar¬ 
ing  ensures  that  both  sectors  are  able  to  bridge  the  critical 
information  gap  between  what  they  know  and  do  not  know. 
Cutting  through  these  knowledge  gaps  ultimately  facilitates 
the  real-time  situational  awareness  necessary  to  defend  cy¬ 
berspace.  Together,  we  can  develop  a  trustworthy,  sustainable, 
and  flexible  information-sharing  environment  that  effectively 
secures  our  Nation’s  cyberspace-including  the  ever-growing 
mobile  domain. 

Roberta  “Bobbie”  Stempfley 

Deputy  Assistant  Secretary 

Office  of  Cybersecurity  and  Communications 

Department  of  Homeland  Security 


CrossTalk-March/April  2012  3 


SECURING  A  MOBILE  WORLD 


.•ill  3G  9:41  AM  *  B 


i 


iPhone 

Malware 

Paradigm 

Aditya  K.  Sood,  Michigan  State  University 
Richard  J.  Enbody,  Ph.D.,  Michigan  State  University 

Abstract.  The  sphere  of  malware  attacks  is  expanding  to  engulf 
the  compact  world  of  smartphones.  This  paper  sheds  light  on 
exploitation  tactics  used  by  malware  writers  in  designing  iPhone 
applications  that  exploit  the  integrity  of  the  victim’s  phone.  Our 
interest  is  in  the  harder  problem  of  malware  on  iPhones  that  are 
not  jailbroken. 


Introduction 

Malware  has  begun  infecting  the  mobile  world.  Several  studies 
[1, 2]  have  been  conducted  showing  how  mobile  malware  is  ex¬ 
ploiting  the  online  world.  Android  malware  infections  are  explod¬ 
ing  as  compared  to  iPhone.  The  primary  reason  is  that  Android  is 
an  open  source  platform  where  as  iPhone’s  iOS  is  closed. 

Our  target  is  to  discuss  the  potential  possibilities  of  malware 
occurrence  in  iPhone  devices.  In  spite  of  the  iPhone’s  strong 
security  platform,  malware  is  making  inroads.  However,  success¬ 
ful  iPhone  exploitation  depends  on  several  factors.  As  we  know, 
Apple  has  implemented  several  security  barricades  in  order  to 
secure  the  iPhone  environment  aided  by  tight  control  of  their  app 
market.  Apple  considers  iPhones  marginalized  by  the  jailbreaking 
process  as  unsecure  since  all  the  inherent  protection  mecha¬ 
nisms  have  been  circumvented  by  the  attacker. 

Is  it  possible  to  write  a  malicious  application  that  may  not 
exploit  security  vulnerability,  but  can  still  perform  some  spyware 
activity?  The  answer  is  yes.  This  is  possible  in  certain  scenarios 
where  a  malicious  application  can  be  designed  to  bypass 
Apple’s  application  review  process  to  execute  illegitimate  opera¬ 
tions  on  an  user’s  iPhone.  In  this  paper,  we  discuss  practical 
scenarios  and  effective  techniques  that  can  be  used  to  host 
malicious  applications  on  non-jailbroken  Apple  iPhones. 

Understanding  Apple’s  iPhone  Applied 
Security  Model 

Apple  enforces  strict  security  features  in  order  to  protect  the 
integrity  of  iOS.  Its  security  model  has  the  following  features: 

•  With  the  advent  of  iOS  4,  Apple  introduced  a  new  data  pro¬ 
tection  procedure  in  which  stored  data  is  secured  using  hard¬ 
ware  encryption.  The  device  stores  the  user  passcode  key  on  an 
internal  chip  using  256-bit  encryption.  The  Unique  ID  (UID)  of 
the  devices  is  used  as  a  key  to  encrypt  a  file  on  iPhone. 

•  The  iOS  environment  is  divided  into  two  main  partitions.  Similar 
to  UNIX,  the  root  partition  manages  the  kernel  and  base  OS.  The 
user  partition  contains  third-party  applications  and  data.  All  applica¬ 
tions  run  in  a  user  mode  with  a  standard  set  of  access  rights  and 
built-in  restrictions.  The  iOS  system-level  binaries  are  related  to 
OS  X  and  Darwin.  In  order  to  preserve  the  integrity  of  applications, 
Apple  implements  a  code  signing  process  [8].  The  code  signature 
consists  of  three  parts.  First,  the  signature  consists  of  a  UID  that 

is  present  in  the  info.plist  files  under  CFBundleldentifier  structure. 
Second,  it  requires  a  seal  that  is  built  from  hashes  and  checksums 
of  various  files  and  other  components  of  the  application  bundle. 
Third,  it  requires  a  digital  signature.  All  the  signatures  are  stored 
in  the  MACH-0  header  format.  Code  signing  code  verification  is 
implemented  in  a  kernel  level  using  the  execv  ()  command. 

•  Third-party  applications  running  on  iOS  are  sandboxed  [9]. 

This  concept  is  implemented  to  force  privilege  separation  among 
different  components  in  iOS.  It  means  that  third-party  applica¬ 
tions  are  not  able  to  run  code  at  kernel  level— a  secure  practice  to 
avoid  exploitation  of  privileges.  The  application  sandbox  is  imple¬ 
mented  using  three  techniques.  First,  entitlements  which  decide 
the  functionality  of  the  application.  Second,  containers  that  provide 
an  application  directory  for  supplying  read/write  operations.  Third, 
powerbox  which  provides  a  secure  way  to  open  and  handle  dialog 
boxes.  Together  these  three  methods  collaboratively  form  the  appli¬ 
cation  sandbox.  Of  greatest  interest  to  malware  writers,  third-party 
applications  are  not  allowed  to  interact  with  kernel-level  extensions. 
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Anatomy  of  Jailbreaking 

For  completeness,  let  us  take  a  brief  look  at  jailbreaking. 

This  attack  exploits  vulnerabilities  in  browser,  plugin,  and  iOS 
components  to  take  control  of  a  victim’s  iOS  device.  As  a  result, 
jailbreaking  [3,  4]  culminates  in  a  complete  compromise  of  the 
iOS  device.  It  primarily  uses  security  vulnerabilities  that  provide 
root  control  of  the  device.  Once  the  vulnerability  is  exploited,  the 
attacker  is  able  to  run  his  native  code  and  turn  the  victim’s  iOS 
device  into  a  weapon.  Jailbreaking  also  deploys  code  signing 
bypass  mechanisms  [5]  in  order  to  install  open  source  packages 
such  as  Cydia  [6].  It  is  also  possible  to  spread  malware  after 
jailbreaking.  In  2009,  a  default  SSH  password  vulnerability  was 
exploited  on  jailbroken  iPhones  to  propagate  the  iKee  [7]  worm 
and  its  variants. 

iPhone  Malware-Exploitation  Model 

A  malware  infection  in  an  iPhone  can  be  categorized  into 
three  distinct  classes: 

•  The  first  class  of  malware  results  from  exploitation  of 
security  vulnerabilities  to  get  root-level  access.  Jailbreaking  falls 
into  this  category.  Once  rooted,  attackers  can  start  services  on 
the  iPhone  to  turn  into  a  malicious  entity  for  spreading  malware. 
In  this  case,  the  attacker  has  to  target  a  specific  set  of  victims. 

It  is  difficult  because  it  becomes  an  action  by  choice  whether 
the  user  wants  to  jailbreak  his  or  her  iPhone  or  not.  As  a  result, 
attackers  force  the  user  to  visit  a  malicious  domain  using  social 
media  tricks  to  download  the  malicious  code.  In  a  real-time 
environment,  it  is  hard  to  spread  this  class  of  malware  on  a  large 
scale  as  there  is  a  trust  layer  that  Apple  provides  its  users  by 
having  applications  hosted  on  Apple’s  online  store.  The  malware 
exploits  the  root  privileges  as  the  kernel  is  already  compromised 
after  the  exploitation  of  the  security  vulnerability.  iPhone  rootkits 
[10]  are  also  classified  into  this  class.  For  example,  the  Dutch 
iPhone  ransomware  [1  1]  belongs  to  this  category  of  malware. 

•  The  second  class  of  malware  exploits  the  default  security 
model  of  Apple.  This  is  basically  exploited  by  spyware  applica¬ 
tions  that  look  legitimate  and  bypass  Apple’s  App  Store  verifica¬ 
tion  process.  Once  in  the  App  Store,  infection  is  easier  as  the 
malicious  application  can  be  easily  disseminated  to  a  number 

of  iOS  users.  The  malicious  application  might  not  be  able  to 
compromise  the  kernel  as  it  runs  in  the  sandbox,  but  it  can 
definitely  steal  users’  sensitive  information,  history,  address  book 
contacts,  and  so  on.  This  class  of  malware  is  a  classic  example 
of  iPhone  spyware  that  exploits  the  trust  boundary  between  the 
user  and  App  Store.  For  example,  SpyPhone  [1 2,  1 3]  falls  into 
this  category  of  malware. 

•  The  third  type  of  malware  is  a  hybrid  of  both  classes  of 
malware  discussed  above.  Hybrid  malware  is  triggered  through 
a  generic  application  that  is  hosted  on  the  App  Store.  When 

a  user  downloads  it,  at  first  it  looks  legitimate  but  behind  the 
scenes  it  starts  sending  texts  to  the  phone  numbers  listed  in  the 
contacts  directory  of  the  victim’s  iPhone.  The  text  itself  carries 
a  link  to  a  malicious  website  that  serves  a  jailbreaking  code. 
Drive-by  download  attacks  are  used  extensively  for  spreading 
this  class  of  malware.  For  example,  iSAM  [1 4]  is  a  hybrid  class 
of  iPhone  malware. 

The  lifecycle  of  mobile  malware  is  presented  in  Figure  1. 
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Figure  1 :  Lifecycle  of  Mobile  Malware 


Inside  the  Apple  Kill  Switch- 
Remotely  Deactivating  Applications 

iOS  has  the  built-in  protection  of  a  kill  switch  [15,  16]  that  en¬ 
ables  Apple  to  kill  a  malicious  application  that  does  not  comply 
with  its  policies.  Applications  installed  on  the  iPhone  regularly 
correspond  back  to  the  App  Store  to  provide  updates  about  the 
state  of  the  device.  Apple  uses  blacklisting  with  a  list  of  applica¬ 
tions  that  are  malicious  and  should  be  turned  off  remotely.  It  is 
kept  in  the  “unauthorzeapps”  file  on  an  Apple  server.  We  per¬ 
formed  a  quick  check  on  a  required  URL  in  order  to  see  which 
applications  are  blacklisted.  Figure  2  shows  that  currently  there 
are  no  applications  marked  as  unauthorized. 


Mozilla  Firefox 

file  £dit  ^iew  History  Bookmarks  Jools  Help 

I  |_J  https:  .  iphone-serv  I  unauthonzedApps  |  +  _ 

•  S/  Apple,  Inc  (US)  https  iphone-services  apple.com  clbl  unauthonzedApps  "  '  C  •  P  9  E 

|£jj  Most  Visited  ^  Latest  Headlines  ^  Getting  Started  Inbox  :*>  Malware  at  Stake  [j  nav_online  html 

(  "Date  Generated"  =  "2011-09-27  21:10:05  Etc/GMT,  "BlacklistedApps"  =  (};  } 


►  Start  Q  Stop  X  Clear  Ik[  |  (V  Autoscroll 

Started  Time  Sent  Received  Method  Result  Type  URL 

00:00:05.599  0.127  652  244  GET  200  text  html  https  iphone- services  apple  com  clbl  unautho 

|  Headeis  |  Cookies  |  Query  String  |  POST  Data  |  Content 


Request  Header 

Value 

Response  Header 

Value 

(Request-line) 

GET  clbl  unauthonzedApps  HTTP  1. 1 

- 

(Status-line) 

HTTP/ 1 l 200  Apple  WebObjects 

Host 

iphone-services.apple.com 

Content- Encoding 

gap 

Usei-Agent 

Mozilla  5  0  (Windows  NT  6  0  WOW64;  iv  6  0  2)  Gecko  201001 

x-  webobjects-  load 

0 

Accept 

text,  html  applic  ation  xhtml  ♦xml  application  xml  q=0. 9 

5 

C  ontent-Type 

teat  html  charset=utf-t 

Accept-Language 

en-us,en;q=0.5 

Content- Length 

9) 

Accept-Encoding 

gztp  deflate 

Accept- Charset 

ISO-S«59-lutf-S;q=0.7  :q=0.7 

Connection 

keep-alive 

- 

Figure  2:  Blacklisted-Unauthorized  Apps  Check 

This  functionality  is  distinct  from  removing  the  applications  from 
the  App  Store  because  this  procedure  is  designed  to  deactivate 
rogue  applications  remotely.  It  seems  like  Apple  usually  removes 
the  application  directly  from  the  App  Store.  However,  the  remote 
deactivation  process  exists  as  a  proactive  defense. 
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Listing  1 :  Sandbox  profiles 

kSBXProfileNoNetwork  (=  "nonet") 
kSBXProfileNoInternet  (=  "nointernet") 
kSBXProfilePureComputation  (=  " pure-computotion") 
kSBXProfileNoWriteExceptTemporary  (=  "write-tmp-only") 
kSBXProfileNo Write  (=  "nowrite") 


Listing  2:  Obfuscation  using  NSString  Object 

(NSString  *)obfuscate_code:(NSString  *)string  withKey:(NSString  *) 
key  { 

II  Create  data  object  from  the  string 

NSData  *data  =  [string  dotoUsingEncoding:NSUTF8StringEncoding ]; 
chor  *code_ptr  =  (char  *)  [raw_data  bytes]; 

II  Mapping  the  pointer  to  key  data 

char  *k_data  =  (char  *)  [[key  dataUsingEncoding:NSUTF8StringEncoding]  bytes]; 
char  *key_ptr  =  k_data; 
int  key_index  =  0; 

II  For  each  character  in  data,  xor  with  current  value  in  key 

for  (int  x  =  0;  x  <  [raw_data  length ];  x++)  { 

II  Apply  XOR  operation  on  every  character 

*code_ptr  =  *code_ptr++  A  *key_ptr++; 

if  (++key_index  ==  [keyjength])  key_index  =  0,  key_ptr  =  k_data; } 

return  [[[NSString  alloc]  initWithData:data  encoding:NSUTF8StringEncoding]  autorelease];} 


App  Store  Application  Review-Dependencies  and  Reality 

There  are  not  many  details  available  about  Apple’s  app  review 
procedures.  However,  based  on  a  developer’s  view  some  details 
can  be  deduced.  Some  of  the  procedures  implemented  by  the 
App  Store  are  as  follows: 

•  The  App  Store  strictly  requires  a  developer  to  be  enrolled 
in  the  Apple’s  iPhone  Developer  program  [19].  In  order  to  get 
the  approval,  the  developer  has  to  submit  a  binary  and  not  the 
source  code,  which  in  turn  means  that  detailed  source  code 
analysis  is  not  a  part  of  the  verification  process.  The  App  Store 
usually  checks  for  user  interface  inconsistencies,  private  API 
calls  and  malware.  However,  malware  scrutiny  depends  on  the 
malware  exploitation  model  mentioned  earlier.  It  is  hard  to  infer 
details  of  the  Apple  application  review  process,  but  dynamic  and 
static  analysis  (pattern  matching)  are  thought  to  be  a  part  of 
the  process.  Given  what  we  know  about  the  review  process,  it  is 
possible  that  stealthy  programming  techniques  may  be  able  to 
circumvent  the  detection  modules. 

•  The  Apple  iPhone  Licensing  Agreement  [20]  requires  a 
developer  not  to  perform  reverse  engineering  tactics  on  the 
applications  hosted  on  the  App  Store  and  software  developer  kit 
components.  Based  on  this  fact,  it  seems  reasonable  to  assume 
that  Apple  itself  is  following  this  practice  and  is  not  performing 
reverse  engineering  on  submitted  applications.  In  practice,  it  is 
not  feasible  to  reverse  engineer  the  thousands  of  applications 
submitted  on  a  weekly  basis. 

•  Most  mobile  malware  aims  to  steal  a  user’s  data  at  the  appli¬ 
cation  layer.  In  spite  of  Apple’s  restrictive  policies,  default  access 
to  user  data  is  available  to  any  application  running  on  an  iPhone. 
The  sandboxed  environment  prevents  applications  from  interact- 
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ing  with  each  other  but  a  malicious  application  can  subvert  the 
trust  boundary  of  another  application.  In  addition,  the  sandbox 
facilitates  the  process  of  preventing  the  background  activities 
that  are  possible  in  jailbroken  iPhones.  Listing  1  shows  the  dif¬ 
ferent  set  of  sandbox  profiles  [22]  available. 

•  Malicious  applications  have  been  hosted  in  the  App  Store  in 
the  past.  For  example,  Aurora  Feint  [1  7]  was  considered  mali¬ 
cious  because  the  application  uploaded  users’  contacts  to  the 
developer’s  server  which  is  a  straightforward  breach  of  privacy. 
Another  example  is  Pinch  Media  [18]  that  followed  the  same 
practices  of  breaching  privacy. 

Obfuscation-Bypassing  Blacklisting 

Obfuscation  can  be  useful  for  legitimate  developers  as  well 
as  for  malware  writers.  Obfuscation  is  used  to  prevent  the 
exposure  of  API  functionality.  For  example,  best  practices  sug¬ 
gest  avoiding  the  embedding  of  hard-coded  credentials  in  the 
application.  However,  developers  sometimes  hide  keys  in  the 
code  using  obfuscation  or  store  credentials  on  a  Webserver  and 
rewrite  queries  after  verification.  That  is,  developers  implement 
obfuscation  modules  for  security  purposes.  Such  code  needs  to 
pass  security  testing.  Apple  requires  the  application  to  be  robust 
in  nature.  As  long  as  the  iPhone  application  is  stable  and  does 
not  crash,  the  App  Store  easily  accepts  an  application  having 
obfuscated  modules. 

While  obfuscation  is  used  by  legitimate  developers  to  prevent 
information  leakage,  a  malware  writer  can  use  obfuscation  to 
bypass  the  App  Store  verification  process. 

Most  of  the  static  analysis  tools  use  blacklisting  in  which  a  cer¬ 
tain  set  of  strings  are  blacklisted.  When  the  scanner  runs  the  appli¬ 
cation  code  it  matches  blacklist  patterns  using  regular  expressions. 
Knowing  this,  it  is  possible  to  bypass  the  static  analysis  tool  using 
obfuscation.  Let  us  consider  an  example;  In  iPhone  applications, 
strings  are  declared  as  NSString  [21]  which  are  immutable  and 
represented  as  an  array  of  Unicode  characters.  Listing  2  shows  a 
prototype  of  implementing  obfuscation  using  NSString  object. 

It  is  possible  to  obfuscate  the  strings  in  an  iPhone  applica¬ 
tion  and  then  deobfuscate  them  at  run  time.  There  are  many 
algorithms  to  perform  this  functionality.  However,  the  XOR 
operation  is  an  effective  way  of  obfuscating  strings.  Generally, 
the  following  steps  can  result  in  implementation  of  obfuscated 
code  in  iPhone  applications: 

•  The  first  step  is  to  create  a  data  object  from  the  required  string. 

•  The  second  step  involves  the  declaration  of  pointers  to  the 
data  and  encryption  key  to  be  obfuscated. 

•  The  third  step  involves  the  implementation  of  counter  that 
runs  through  every  character  in  a  string  and  embeds  a  key  using 
the  XOR  operation. 

Code  Hiding  in  Objective-C  and  Symbols  Stripping 

Apple  is  very  strict  in  its  review  policy  about  using  private 
API  functions  that  are  not  documented  because  these  hidden 
methods  can  be  used  by  malware.  Generally,  applications  using 
private  API  functions  are  rejected  by  the  App  Store.  Objective-C 
does  not  provide  support  for  private  methods,  but  it  is  still  pos¬ 
sible  to  write  methods  that  hide  malicious  code.  Below  are  the 
two  most  widely  implemented  steps: 

•  Objective-C  has  a  dynamic  resolution  feature  in  which  a 
method  is  bound  during  compile  time.  The  attacker  can  define  a 
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secret  function  whose  signature  matches  Objective-C  imple¬ 
mentation.  The  secret  function  is  declared  in  the  class  method. 
When  that  method  gets  called  for  the  first  time,  the  malicious 
code  is  bound  to  the  class  privately.  This  type  of  procedure  is 
used  to  circumvent  code  detection  using  a  tool  such  as  Class- 
Dump.  Listing  3  shows  a  code  prototype  that  uses  dynamic 
method  resolution. 

However,  a  skilled  analyst  may  be  able  to  figure  out  the 
presence  of  stealth  code.  For  example,  running  Otool  on  a 
particular  method  results  in  the  list  of  selectors  that  are  used  by 
the  respective  method.  However,  it  is  possible  to  obfuscate  the 
method  by  generating  selectors  at  run  time  using  “ NSSelector - 
FromStringO"  functions. 

•  In  Objective-C,  it  is  also  possible  to  create  functions  that 
work  similarly  to  instance  methods.  It  means  functions  can 
access  instance  variables  easily.  These  types  of  functions 
should  be  defined  in  the  class  implementation.  It  is  not  a  normal 
way  of  doing  things,  but  the  desired  method  never  appears  in 
the  Objective-C  run  time  which  hampers  verification.  Listing 
4  shows  the  declaration  of  malicious  function  hide_me  with 
instance  variables.  The  function  hide_me  does  not  have  its  own 
selector  rather  it  uses  the  selector  of  stealth  instance  (public) 
method  defined  in  the  class. 

The  two  methods  discussed  provide  a  way  to  design  code 
which  can  hide  from  tools  that  examine  code  so  they  can  be 
accepted  by  the  App  Store. 

Additionally,  stripping  is  a  technique  used  in  UNIX  platforms 
to  remove  unnecessary  information  from  a  binary  and  object 
files  to  improve  performance.  A  malicious  developer  can  use 
stripping  to  remove  information  prior  to  submission  of  an  ap¬ 
plication  binary  to  the  App  Store.  Doing  so  removes  clues  that 
might  indicate  the  malicious  nature  of  the  code. 


Listing  3:  Code  hiding  using  dynamic  resolution 

//  Setting  a  Class  Interface  as  Secret 

@interfoce  Secret  () 

//  secret  function  is  defined  in  the  class  method 
void  hide_me(id  self  SEL_command); 

@end 

II  Implementing  Class 

@ implementation  Secret 
(a) synthesize  handle; 

II  Selecting  hidejne  secret  function  and  binding  into  the  class  method 

+  (BOOL)resolvelnstanceMethod:  (SEL)aSel  { 
iffaSel  ==  @selector(hide_me))  { 
class_addMethod(self  aSel ,  (IMP)hide_me,  "v@:"); 
return  YES; 

} 

return  [super  resolvelnstanceMethod:  aSel]; 

} 

II  This  is  an  Instance  Method  holding  a  reference  to  hidejne 

-  (void)stealth  {[self  hide_me];} 

void  hide_me(id  self  SEL_command)  { 

HIDE(@"lnside  hide_me:  %d",  (LMethod  *)self)->handle); 

} 

@end 

//Class  Dump  Output 

@interface  Secret :  NSObject  { int  handle; } 

II  Tool  does  not  provide  information  about  hidejne  after  static  discovery  of  Class  Method 

+  ( BOOL)resolvelnstanceMethod:(SEL)argl ; 

@property(nonatomic)  int  handle;  //  @synthesize  handle; 

II  Class  Dump  only  lists  the  Instance  Method 

-  ( void  [stealth ; 

@end 

Listing  4:  Code  hiding  function  variables  as  instance  methods 


Exploiting  the  Remote  Server  End  Points 

Generally,  all  iPhone  applications  communicate  back  with  a 
Webserver  (HTTP  End  Point)  in  order  to  exchange  data  between 
the  application  and  the  server  on  a  regular  basis.  It  is  possible 
for  malware  to  exploit  the  HTTP  end  point  mechanism.  At  the 
time  of  verification,  Apple  performs  a  behavioral  analysis  of  the 
application  and  scrutinizes  the  communication  pattern.  At  the 
time  of  submission,  the  attacker  can  make  the  HTTP  end  point 
legitimate  and  once  approved  by  Apple,  the  same  HTTP  end 
point  can  be  used  to  serve  the  exploit  code  which  is  download¬ 
ed  into  the  victim’s  phone  when  the  application  interacts  with  a 
remote  server.  For  example:  consider  the  following  scenario: 

•  Attacker  writes  an  application  that  interacts  with  a 
remote  server  on  the  URL  <http://www.mal-app-test.com/error. 
asp  >.  The  error.asp  webpage  validates  the  resource  and  if  that 
resource  is  not  present  then  it  raises  an  error. 

•  During  the  verification  process,  Apple  finds  it  legiti¬ 
mate  and  the  application  is  treated  as  good  enough  to  host  on 
the  App  Store. 

•  Once  the  application  is  hosted,  it  is  possible  to  ma¬ 
nipulate  the  “error.asp”  webpage  to  deliver  exploit  code  that  is 
downloaded  into  the  device  and  performs  malicious  functions. 

This  is  a  legitimate  scenario  that  can  be  exploited  to  trigger 
malware  infections  in  an  iPhone. 


(void)stealth  {  hide_me(self  _cmd);} 

Cautionary  Steps 

Users  play  a  critical  role  in  the  success  of  malware.  There  are 
a  number  of  steps  that  a  user  can  follow  to  reduce  risk.  These 
proactive  steps  are  applicable  to  every  smartphone  whether 
Android  or  iPhone  and  are  discussed  as  follows: 

•  Mobile  users  should  not  install  any  unauthorized  application 
from  third-party  resources.  The  installed  applications  must  be 
verified  and  authorized  from  legitimate  vendors. 

•  The  users  should  think  twice  prior  to  clicking  any  URL  from  non¬ 
legitimate  resources.  For  example:  users  should  be  careful  while  chat¬ 
ting  on  social  media  applications  such  as  Facebook  and  Twitter.  Push 
notification  messages  should  be  scrutinized  critically  prior  to  executing 
any  action  based  on  the  information  in  a  message.  E-mail  attachments 
should  not  be  opened  directly  until  the  user  is  sure  about  legitimacy. 

•  It  is  always  advised  to  install  anti-virus  software  on  your 
mobile  device  which  scans  the  device  for  potential  suspicious 
activities  and  notifying  users  about  changes  in  the  system. 

•  Usage  of  strong  passwords  and  avoidance  of  default  secu¬ 
rity  policies  is  always  preferred. 

•  Users  should  carefully  analyze  the  behavior  of  their  mobile 
phones  against  any  types  of  anomalous  activities  such  battery  drain¬ 
age,  high  Internet  data  usage,  and  slower  execution  of  applications. 
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Conclusion 

In  this  paper,  we  have  discussed  the  state  of  iPhone  malware. 
There  is  no  doubt  that  Apple  has  designed  a  robust  verifica¬ 
tion  policy  but  it  is  still  possible  to  create  stealthy  malware  that 
can  bypass  Apple’s  verification  process.  However,  doing  so 
requires  devising  a  malicious  application  in  an  intelligent  way 
using  stealthy  techniques  such  as  code  obfuscation,  stripping, 
and  code  hiding.  We  believe  that  malware  poses  an  increasingly 
serious  challenge  to  the  security  of  our  devices  and  we  need  to 
be  proactive  in  our  defenses  to  ensure  the  security  of  our  data 
and  privacy. 
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Abstract.  We  have  always  said  that  the  strength  of  an  organization’s  security  pro¬ 
gram  is  only  as  strong  as  its  weakest  link.  Today  in  most  organizations,  this  weakest 
link  is  the  use  of  smart  devices  like  iPads,  iPhones,  and  Android  phones.  This  article 
provides  a  practical  approach  to  managing  and  securing  these  smart  devices. 

Introduction 

Most  organizations  in  the  past  deployed  BlackBerry  devices 
for  corporate  use  to  access  e-mail  and  provide  messaging  for 
their  employees.  These  organizations  knew  that  the  security  on 
BlackBerries  complied  with  their  security  policies.  A  few  years 
ago,  a  genius  named  Steve  Jobs  changed  all  that.  He  an¬ 
nounced  devices  like  iPads  and  iPhones.  And  of  course,  Google 
was  not  going  to  be  left  behind.  They  made  their  Android  OS 
available  to  phone  manufacturers  for  free. 

With  the  advent  of  these  smart  devices  like  iPads,  iPhones, 
and  Android  phones,  organizations  are  now  searching  for  a 
secure  solution  for  these  devices  similar  to  the  one  they  have 
for  their  BlackBerry  devices.  Several  vendors  have  developed 
Mobile  Device  Management  (MDM)  solutions  to  assist  organiza¬ 
tions  in  managing  their  smart  devices. 

Typically,  IT  organizations  are  chartered  to  manage  these 
devices.  Before  they  select  an  MDM  solution,  they  must  engage 
the  key  departments  within  the  organization  to  understand  the 
planned  usage  of  these  smart  devices  and  gather  requirements. 
Most  IT  organizations  are  surprised  when  they  hear  the  market¬ 
ing  department  say  how  they  are  planning  to  use  the  smart 
devices,  or  better  yet  hear  how  the  CEO  or  the  CFO  is  planning 
to  utilize  a  newly  acquired  iPad. 

We  suggest  a  1 0-step  approach  for  organizations  to  plan, 
implement  and  manage  an  MDM  program. 

Step  1  During  the  acceptable  use  policy  development, 
several  questions  should  be  asked  and  answered  by  key  depart¬ 
ments  within  the  organization.  These  questions  help  identify  the 
requirements  and  provide  input  into  the  next  step  of  defining  the 
IT  architecture.  It  helps  to  identify  the  right  solutions,  after  ask¬ 
ing  the  right  questions  such  as: 


•  Will  all  devices  be  deployed  by  the  organization  or  will  users 
be  allowed  to  bring  their  own  device? 

•  Is  there  a  need  to  separate  personal  vs.  corporate  data 
on  devices? 

•  Is  personal  use  allowed  or  only  corporate  use?  (Can  users  play 
Angry  Birds?) 

•  Will  employees  agree  to  abide  with  corporate  security  policies 
(e.g.  remote  wipe,  or  recording  of  their  phone  calls). 

•  Will  confidential  data  be  allowed  on  smart  devices  and  how  it 
will  be  monitored  and  controlled? 

•  What  type  of  smart  devices  will  be  allowed?  Apple  only? 
Android  only? 

•  How  are  you  going  to  manage  backing  up  devices? 

•  Do  devices  need  to  connect  to  a  corporate  network? 

•  Which  apps  would  you  like  to  deploy?  Corporate  apps? 

Do  you  need  your  own  marketplace? 

Step  2  Once  the  answers  to  these  questions  have  been 
obtained,  a  draft  IT  architecture  should  be  designed  to  support 
the  deployment  of  an  MDM  solution.  For  example:  an  answer  to 
the  question  “corporate  device  vs.  personal  device”  may  imply 
whether  an  organization  can  wipe  out  the  entire  device  if  it  is 
lost,  or  if  they  need  a  secure  “container”  within  the  device  to 
house  the  corporate  data. 

The  IT  architecture  may  also  address  issues  like: 

•  Cloud-based  solution  vs.  internally  deployed 

•  Hosted  vs.  self-supported 

•  Scalability  and  performance  issues  based  on  number  of  devices 

•  How  current  IT  architecture  will  support  the  mobile  architecture 

Step  3  Once  the  requirements  have  been  defined  and  the 
supporting  IT  architecture  has  been  designed,  security  policies 
to  support  the  mobile  strategy  should  be  developed.  The  secu¬ 
rity  policy  may  address  some  or  all  of  these  issues: 

•  Password  policy  control 

•  Encryption  requirements 

•  Port  control  (Wi-Fi,  Bluetooth,  camera) 

•  Remote  lock/unlock/wipe 

•  Asset  tracking 

•  Device  configuration  (VPN,  e-mail,  Wi-Fi) 

•  Delivery  and  control  of  applications  to  the  device 

•  Blacklisting/whitelisting 

•  Audit  and  monitoring 

Step  4  Now  you  can  use  the  requirements  identified  during 
the  planning  phase  to  select  the  right  MDM  solution.  The  imple¬ 
mentation  of  the  IT  architecture  is  completed  and  the  Proof-of- 
Concept  (POC)  or  pilot  program  implementation  is  completed. 
Typically  a  select  few  devices  are  managed  under  the  POC  or 
pilot  program.  Typically  the  following  steps  are  executed: 

•  E-mails  are  identified  for  the  selected  device  owners 

•  A  self-registry  link  is  sent  to  the  users 

•  Users  enter  the  registry  information  and  obtain  credentials 

•  Security  policies  are  pushed  down  to  the  device 

•  Device  is  ready  for  use 
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Step  5  Enable  the  e-mail,  contact  and  calendar  features 
according  to  the  mobile  architecture  and  policies  defined  during 
the  planning  phase.  Typically,  organizations  combine  the  features 
available  within  the  ActiveSync/Lotus  Notes  features  with  the 
features  in  the  selected  MDM  solution.  This  step  brings  the 
same  functions  that  are  available  on  BlackBerries  to  other  smart 
devices.  At  a  minimum,  organizations  should  enable  the  e-mail, 
contact,  and  calendar  features. 

Step  6  Within  this  step,  organizations  roll  out  custom  mobile 
applications  to  the  smart  devices.  There  are  several  decisions 
you  probably  made  during  the  planning  phase.  You  probably 
answered  these  questions  during  the  planning  phase: 

•  Are  you  going  to  have  your  own  marketplace,  from  where 
your  employees  can  download  applications? 

•  Are  you  going  to  develop  applications  for  Apple,  Android, 
or  both? 

•  Are  most  of  the  applications  going  to  be  browser-based 
applications,  or  will  they  be  native  custom  mobile  applications? 

•  Will  employees  download  these  applications  from  the  Apple 
App  Store  and/or  Android  Market? 

•  Are  you  going  to  develop  these  applications  in-house  or  will  a 
third  party  develop  these  applications  for  you? 


Step  8  During  this  step,  appropriate  measures  are  taken  to 
ensure  that  the  implemented  solution  complies  with  regulatory 
requirements.  If  the  smart  device  is  going  to  contain  financial 
data,  personal  health  data,  personally  identifiable  information, 
or  credit  card  information  (and  most  likely  you  will  if  you  will 
store  e-mails  on  your  smart  device),  this  data  must  be  secured. 
In  addition,  the  installed  mobile  solution  must  have  the  ability  to 
produce  appropriate  reports  to  satisfy  the  audit  requirements  of 
these  regulations. 

Step  9  This  step  is  to  provide  adequate  support  to  monitor 
and  report  on  the  managed  devices.  Examples  of  type  of 
reports  include: 

•  Number  of  devices  supported  and  inventory  of  the  devices 

•  The  current  location  of  each  device 

•  Number  of  remote  wipes  performed  in  a  month/quarter/year 

•  Number  of  stolen/lost  devices 

Step  10:  This  step  provides  the  necessary  support  to  inter¬ 
nal/external  auditors  when  they  perform  their  audits.  More  and 
more  auditors  are  targeting  smart  devices  as  they  are  beginning 
to  agree  that  the  smart  devices  are  becoming  the  “weakest  link” 
of  their  security  program. 


During  this  step,  you  will  need  two  major  processes: 

•  Verify  that  the  source  code  is  written  based  on  the  guidelines 
provided  by  the  Open  Web  Application  Security  Project.  This 
requires  appropriate  source  code  analysis  tools  and  the  ability 
to  perform  penetration  testing  of  the  application. 

•  Incorporate  your  corporate  systems  development  lifecycle 
process  in  the  development  of  mobile  applications. 

Step  7  During  this  step,  the  smart  devices  begin  to  act  like  a 
laptop  and  can  remotely  connect  to  the  corporate  network  and 
access  corporate  resources  like  servers,  LAN  shared  drives  and 
other  corporate  data.  The  focus  during  this  step  is  to  ensure  that 
the  same  rugged  security  features  are  deployed  that  are  used 
for  your  remote  laptop  connections.  You  should  look  into  your 
remote  access  policy  to  ensure  that  it  supports  the  connection 
of  smart  devices  to  the  corporate  network. 

VPN  configuration,  encryption  parameters,  and  virtualization 
concepts  may  come  into  play  as  you  deploy  the  right  solution  for 
this  step. 
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Other  considerations:  Some  of  the  other  considerations 
related  to  smart  devices  may  include: 

•  Evaluate  your  current  e-Discovery  process  to  see  if  smart 
devices  need  to  be  included  in  this  process. 

•  Litigation  Hold:  during  the  litigation  process,  it  may  become 
important  to  include  smart  devices  during  litigation  hold. 

•  Export  control  laws:  if  your  organization  deals  with  certain 
technologies  which  have  export  control  requirements,  you  may 
want  to  track  smart  devices  to  ensure  that  the  device  is  not  in 
the  countries  where  export  control  laws  may  be  violated. 

In  summary,  an  MDM  software  solution  plays  a  key  role  in 
helping  organizations  manage  and  secure  smart  devices,  but 
preliminary  planning  is  the  key  to  success  when  deploying  your 
smart  device  strategy.^ 
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Abstract.  With  the  proliferation  of  mobile  devices  in  today’s  information-rich 
environment,  the  security  of  data  at  rest  on  the  device  and  in  transit  will  determine 
the  ultimate  usability  of  mobile  devices  in  the  defense  environment  Relying  on 
the  security  models  provided  by  the  major  OS  providers  such  as  Apple’s  iOS  or 
Google’s  Android  is  not  enough  to  meet  the  information  protection  needs  of  the 
defense  environment.  Researchers  at  Southwest  Research  Institute®  (SwRI®) 
are  investigating  the  security  models  available  for  application  development  on  the 
iOS  and  Android  platforms,  the  threats  involved,  methodologies  for  application-level 
data  protection,  the  intersection  between  data  security  and  user  experience,  and 
best  practices  for  ensuring  data  security  within  mobile  applications. 


Introduction 

Today’s  smartphones  and  tablets  are  more  than  communica¬ 
tion  devices.  They  are  hip-mounted  personal  computers,  with 
more  memory  and  processing  power  than  your  laptop  of  just 
a  few  years  ago.  They  are  an  integrated  part  of  our  lives... 
personal  and  professional.  The  information  they  provide  is  so 
vital  that  the  Army  is  piloting  their  use  as  standard  field  issue 
to  every  soldier,  complete  with  combat-focused  applications  [1]. 
However,  smartphones  and  tablets  raise  new  security  issues. 
They  are  more  likely  to  be  lost  or  stolen,  exposing  sensitive 
data.  Malware  risks  are  increased  because  they  connect  to  the 
Internet  directly  rather  than  from  behind  corporate  firewalls  and 
intrusion-protection  systems. 

Security  of  mobile  devices  focuses  on  controlling  access 
through  the  use  of  device  locks  and  hardware  data  encryption. 
While  this  may  be  sufficient  for  individual  users,  it  is  insufficient 
for  defense  needs.  Many  documented  examples  exist  of  hack¬ 
ing  of  the  device  lock,  as  well  as  defeats  of  the  hardware-level 
encryption.  Once  the  device  is  unlocked,  there  is  generally 
unfettered  access  to  all  apps  and  their  associated  data.  Military 
applications  require  additional  application-level  access  controls 
to  provide  data  security.  Unfortunately,  there  are  gaps  in  the 
application-level  security  model  of  the  two  predominant  mobile 
operating  systems:  iOS  from  Apple  and  Google  Android.  Our 
ongoing  research1  looks  to  address  these  gaps  by  developing 
innovative  approaches  for  fine-grained  data  protection  and  ac¬ 
cess  control,  taking  into  account  mobile  device  usage  patterns, 
device  characteristics,  and  usability. 

Threat  Vectors 

Many  threat  vectors  for  infecting  personal  computers  arise 
from  social-engineering  attacks  that  bypass  anti-virus  defenses. 
Similar  techniques  are  used  in  the  smartphone  and  tablet  world 
by  deceiving  users  into  installing  malicious  apps.  Examples 
include  apps  that  gather  personal  information,  track  location, 
and  charge  accounts  by  sending  text  messages  to  premium-rate 
numbers.  Using  a  mobile  device  to  access  corporate  email  or 
other  resources  extends  the  threat  to  the  organization,  including 
the  theft  of  sensitive  data  [2].  With  the  acknowledged  role  of 
mobile  devices  and  social  networks  in  the  revolutions  in  Egypt, 
Libya,  and  Syria,  malware  and  viruses  targeted  at  intelligence 
gathering  and  device-usage  denial  will  increase  significantly  in 
the  future  [3]. 

While  viruses  and  malware  targeting  mobile  devices  would 
share  many  of  the  same  goals  as  on  the  PC,  the  enhanced 
capabilities  of  these  devices  present  expanded  attack  surfaces 
through  sensors  such  as  GPS,  accelerometer,  camera,  micro¬ 
phone,  and  gyroscope.  Recently,  Kaspersky  Lab  discovered  a 
new  threat  involving  the  photo-scanning  of  Quick  Response 
(QR)  codes  [4].  QR  codes  are  2-D  matrix  barcodes  increasingly 
used  in  advertising  and  merchandising  to  direct  mobile-phone 
users  to  a  website  for  further  information  on  the  tagged  item.  In 
this  case,  users  downloaded  what  they  thought  was  a  legitimate 
app,  but  instead  was  malware  that  sent  Simple  Message  System 
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(SMS)  messages  to  a  premium-rate  number  that  charged  for 
each  message  [5].  This  app  could  have  easily  been  reconfigured 
to  send  covert  copies  of  emails  and  text  messages  to  an  intel¬ 
ligence  gatherer  instead. 

In  another  example,  using  the  unique  capabilities  of  a  mobile 
device,  Georgia  Tech  researchers  were  able  to  use  the  phone’s 
accelerometer  to  detect  PC  keyboard  vibrations  and  decipher 
complete  sentences  with  up  to  80%  accuracy.  This  was  done  by 
placing  the  phone  within  three  inches  of  the  keyboard  of  a  PC, 
allowing  the  researchers  to  pick  up  the  keyboard  vibrations  and 
decipher  words  of  up  to  three  to  four  characters  fairly  accurately. 

The  key  to  understanding  the  threat  vectors  of  mobile  devices 
is  realizing  that  the  devices  have  more  input  sources  than  the 
conventional  PC,  and  have  an  extended  range  outside  the  typi¬ 
cal  home  or  office. 

Application  Security  Models:  iOS  vs.  Android 

According  to  Nielsen,  Google’s  Android  is  the  most-used 
mobile  OS,  followed  by  Apple’s  iOS  [6].  The  threat  level  varies 
between  the  iOS  and  the  Android  environments,  due  to  their 
app-distribution  models.  Because  iOS  apps  are  distributed 
only  through  the  Apple  App  Store,  the  Apple  review  process 
substantially  reduces  the  threat  of  downloading  a  malicious  app. 
This  protection,  however,  is  lost  if  a  user  “jailbreaks”  the  device 
and  installs  apps  from  an  alternative  site  or  obtains  illegal  apps 
from  elsewhere. 

The  Android  environment  is  more  wide  open.  Android  apps, 
although  primarily  distributed  through  the  Google  Android  Mar¬ 
ket,  are  legally  distributed  by  other  means.  There  is  no  review  or 
testing  of  apps,  although  apps  require  a  digital  signature  by  the 
developer.  Android  apps  execute  in  a  sandbox  on  the  device  and 
must  ask  the  user  for  permission  to  access  critical  device  re¬ 
sources,  such  as  GPS,  SMS,  and  the  phone  dialer.  Unfortunately, 
it  is  often  difficult  for  a  user  to  determine  whether  the  requested 
permission  is  necessary  for  that  app.  Permissions  are  perma¬ 
nently  attached  to  the  app;  once  the  permission  is  granted,  the 
user  cannot  revoke  it. 

When  we  look  at  the  security  models  of  iOS  vs.  Android,  they 
can  best  be  summed  up  as  “trust  us”  vs.  “trust  them.” 

Apple  iOS 

Apple’s  “trust  us”  model  controls  security  from  malicious  apps 
by  providing  only  one  outlet  for  app  distribution  and  by  tightly 
controlling  the  iOS  Software  Development  Kit  (SDK).  Develop¬ 
ers  submitting  apps  for  distribution  must  register  with  Apple  to 
obtain  certificates  to  build  and  deploy  apps.  All  apps  must  be 
signed  with  the  certificate  assigned  by  Apple.  Apps  must  be 
built  using  Xcode,  Apple’s  own  development  tool,  and  apps  may 
use  only  the  official  iOS  SDK— no  third-party  software  APIs. 
Apple’s  development  program  requires  a  yearly  fee  (currently 
$99),  which  must  be  kept  up-to-date.  Apple  reserves  the  right  to 
revoke  the  developer’s  certificate  at  any  time,  which  will  take  any 
apps  developed  off  the  App  Store  and  prevent  the  developer 
from  distributing  any  further  apps  until  restoring  the  certificate. 
All  apps  submitted  to  Apple  for  distribution  are  reviewed  to  en¬ 


sure  proper  use  of  the  SDK,  adherence  to  the  Program  License 
Agreement,  and  adherence  to  a  long  list  of  app  functionality, 
subject  matter,  and  content  requirements  that  include  ensuring 
the  app  is  not  malware. 

Security  within  iOS  is  fairly  strong,  straight-out-of-the-box,  but 
the  SDK  does  not  provide  additional  support  to  make  apps  more 
secure.  The  device  can  be  controlled  through  the  setting  of  a 
4-digit  pin  or  a  password.  While  this  security  is  not  forced  upon 
the  user,  organizations  that  use  Mobile  Device  Management 
(MDM)  software  for  their  mobile-device  fleet  can  force  the  use 
of  pins  or  passwords,  as  well  as  the  strength  of  those  access 
codes.  Alphanumeric  passwords  offer  better  protection  than 
digit-only  pins,  as  a  Russian  group  showed  in  cracking  the  iOS 
4-pin  device  lock  [7].  Additionally,  iOS  features  an  encryption 
capability  for  data  stored  by  applications.  By  default,  all  “data 
at  rest”  stored  in  the  user  partition  is  automatically  encrypted 
through  hardware-based  encryption.  While  this  would  appear  to 
be  sufficient  protection  for  direct  attacks  against  the  disk,  boot¬ 
ing  the  device  with  an  alternate  OS  can  provide  unencrypted 
access  to  the  disk  [8].  Applications  with  data  files  marked 
“protected”  will  be  software-encrypted  when  stored  on-disk.  De¬ 
cryption  keys  are  accessible  only  when  the  device  is  unlocked. 
The  decryption  keys  are  managed  by  the  iOS  Keychain,  which  is 
always  encrypted  and,  unlike  Keychain  in  the  Mac  OS  X,  is  not 
user  accessible. 

An  additional  security  measure  is  sandboxing  applications 
and  their  data  stores.  Sandboxing  provides  an  app  with  its  own 
process  space  and  prevents  the  app  from  accessing  other 
process  spaces.  Apple  sandboxing  does  not  prevent  malicious 
attacks  against  an  app,  but  it  does  limit  the  damage  done  by 
the  hacked  app  to  other  parts  of  the  device.  iOS  apps  are  not 
allowed  to  start  or  execute  other  apps.  Additionally,  inter¬ 
process  communication  is  allowed  only  through  custom  URL 
handlers,  similar  in  functionality  to  the  http://  and  ftp://  URL 
schemes  of  Internet  browsers. 

It  is  easy  to  see  how  Apple’s  iOS  security  can  be  summed  up 
as  “trust  us,”  given  its  complete  control  over  app  development 
for  their  platform,  from  the  APIs  and  tools  available  for  app  de¬ 
velopment,  to  the  distribution  process,  to  the  device  itself.  SwRI 
researchers  have  found  that  these  mechanisms  can  be  broken 
and  the  app  accessed,  exposing  all  the  data  stored  within. 

The  iOS  SDK  does  not  appear  to  provide  support  for  specific 
application-level  authentication  and  authorization  [9].  Using  an 
enterprise  mobile-device  management  system  can  force  the 
use  of  the  device  lock  to  registered  devices  (such  as  using  an 
alphanumeric  password  of  sufficient  anticracking  strength),  but 
apps  cannot  force  the  use  of  device  locking  as  a  requirement 
for  installation  and  execution. 

Google  Android 

Google  took  a  different  approach  with  the  Android  OS. 
Whereas  Apple  controls  everything  related  to  the  app  devel¬ 
opment  and  distribution  process,  Google  developed  Android 
as  an  open  source  model.  Android  developers  are  free  to  add 
to  the  API,  use  third-party  APIs,  and  distribute  apps  through 
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Covert  Channel 


Figure  1  Using  covert  channels  to  subvert  the  Android  sandbox-permission  model 


any  means  they  see  fit  While  all  Android  apps  must  be  signed 
with  a  certificate,  developers  can  create  their  own  certificates 
without  using  a  certified  certificate  authority.  Android  provides 
the  capability  for  greater  application  security  than  iOS,  but  the 
security  model  is  definitely  “trust  them,”  as  in,  “do  you  trust  the 
developer  of  the  app  is  providing  you  a  legitimate  app  that  will 
provide  its  stated  service  in  the  manner  described  by  the  app 
developer  and  not  try  to  steal  information  from  you  or  try  to 
damage  your  mobile  device?”  Still,  Android  is  not  without  some 
basic  security  measures. 

Android  security  is  based  on  the  Linux  kernel  model,  which 
silos  applications  into  process  sandboxes  that  can  reach  out  of 
the  sandbox  via  user-granted  permissions.  All  apps  are  assigned 
a  Unique  User  ID  (UID)  when  they  are  installed.  However,  un¬ 
like  Linux,  this  UID  is  truly  unique  to  each  app  rather  than  to 
each  user  on  a  Linux  system.  Any  data  the  app  stores  on  the 
device  is  tagged  with  this  UID,  and  an  app  can  access  only  its 
U ID-tagged  data  unless  granted  extra-sandbox  permissions  to 
other  data  sources.  Unlike  iOS,  Android  applications  can  share 
resources  and  data  through  the  declaration  of  permissions. 

Android  grants  permissions  to  resources  on  a  per-application 
basis  during  the  installation  of  the  application.  The  user  is  given 
a  one-time  option  to  install/not  install  the  application  after 
reviewing  the  resources  requested  by  the  application,  thereby 
granting  all  the  permissions  or  not  installing  the  application  at 
all.  Applications  requiring  dangerous  combinations  should  not  be 
installed.  For  example,  it  may  be  legitimate  for  an  application  de¬ 
signed  to  provide  current  weather  conditions  to  request  access 
to  GPS  and  networking  so  the  user  does  not  have  to  continu¬ 
ously  input  a  location;  but  if  the  application  also  requests  access 
to  telephony  (i.e.,  dialing  phone  numbers),  a  red  flag  should  be 
raised.  Unfortunately,  the  stock  Android  OS  does  not  currently 
support  selectively  granting  permissions  at  install  time;  however, 
third-party  add-ons  have  begun  implementing  this  feature  [10]. 


Permissions  cannot  change  once  the  app  is  installed.  This  does 
help  somewhat.  Once  installed,  an  app  cannot  grant  itself 
additional  permissions. 

A  savvy  user  aware  of  the  dangerous  combinations  of 
resource  access  can  significantly  reduce  the  security  threat  to 
their  mobile  device.  However,  one  research  effort  [1 1]  demon¬ 
strated  how  to  subvert  Android’s  sandboxing-and-permission 
model  through  two  colluding  Trojan -packaged  applications  using 
a  covert  channel.  The  first  application  requires  permission  to  the 
microphone  and  is  enticing  to  install.  The  second  application  re¬ 
quires  permission  to  networking,  and  its  installation  is  launched 
by  the  first.  Access  to  microphone  and  networking  is  a  danger¬ 
ous  combination  if  requested  by  a  single  application.  The  Trojan 
in  the  first  application  pulls  out  sensitive  data,  such  as  credit 
card  and  PIN  numbers,  using  sophisticated  tone-and-speech- 
recognition  algorithms.  After  extracting  the  sensitive  data,  the 
first  application  changes  the  vibration  settings  (covert  channel) 
on  the  phone,  which  then  triggers  notifications  to  the  colluding 
second  application,  as  shown  in  Figure  1. 

Accessing  vibration  settings  does  not  currently  require  any 
permissions  and  does  not  leave  any  traces.  Through  its  net¬ 
working  privileges,  the  second  application  then  transmits  the 
sensitive  data  to  the  interested  party.  This  approach  is  attrac¬ 
tive,  because  high-value  information  is  extracted  locally  on  the 
phone,  significantly  reducing  the  amount  of  data  needed  to  be 
transmitted  to  and  processed  by  the  malware  master.  To  mediate 
this  vulnerability,  the  authors  of  this  research  suggest  Android 
restrict  covert  communication  through  event  notification. 

Since  Android  is  an  open  API  designed  to  run  on  a  wide 
range  of  hardware,  whole-device  encryption  is  not  provided  by 
default  unless  it  is  an  added  feature  of  the  phone  maker  or  car¬ 
rier.  With  Android  3.0,  full-device  encryption  is  now  available  and 
being  implemented  by  some  MDM  providers. 
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Application-level  Data  Protection 

As  organizations  utilize  mobile  devices  as  enhancements  or 
replacements  for  computers,  many  will  soon  work  to  develop 
custom  applications  designed  for  their  own  needs.  These  ap¬ 
plications  may  contain  confidential,  proprietary  information  that 
will  need  additional  protections  than  are  offered  at  the  device  or 
hardware  level. 

The  typical  method  to  protect  application  data  is  to  protect  ac¬ 
cess  via  a  login  specifically  for  the  application.  We  do  this  on  our 
PCs  with  applications  that  need  an  additional  level  of  protection 
over  and  above  the  OS-level  screen  lock;  sometimes  to  protect 
specific  information,  sometimes  to  log  who  is  currently  using  the 
application,  many  times  for  both.  The  scenarios  required  for  ap¬ 
plication  locking  on  PCs  also  exist  on  mobile  devices. 

For  iOS-based  devices,  it  appears  the  only  solutions  are 
custom  security  codes  for  each  app  or  the  use  of  a  third-party 
solution,  which  requires  jailbreaking  the  phone.  There  does  not 
appear  to  be  any  support  in  the  iOS  SDK  for  application-level 
authentication  and  authorization.  A  search  of  the  web  reveals 
LockDown  Pro  and  Locktopus,  designed  to  specify  application- 
level  password  protection  to  apps  on  the  iPhone;  however,  both 
require  the  Cydia  client  and  a  jailbroken  phone.  This  is  not  to  say 
application-level  security  cannot  be  done  within  iOS. 

Android  is  different.  The  API  includes  java.security  and  javax. 
crypto  packages,  which  provide  security  mechanisms  that  can 
be  included  into  any  app.  Additionally,  since  the  Android  SDK  is 
open-source,  you  can  develop  and  roll-your-own  application-lev- 
el  security  programmatically.  The  web  shows  many  apps  already 
available  for  locking  existing  applications  on  an  Android  device, 
and  they  do  not  require  rooting  the  device  to  enable  app  locking. 

In  both  Android  and  iOS,  the  assumption  is  “one  device,  one 
user.”  It  does  not  take  much  imagination  to  conceive  scenarios 
where  tablets  and  smartphones  become  like  radios  in  a  shop, 
lined  up,  charged,  and  ready  for  the  next  user.  A  flight-line 
maintenance  shop  might  have  several  tablets  available  for 
maintenance  crews,  who  grab  one  on  the  way  to  turn  around  an 
airplane  for  another  mission.  Using  apps  on  the  tablet  to  record 
maintenance  done,  order  parts,  configure  the  plane  to  mission 
parameters,  etc.,  it  is  easy  to  see  where  specific  application 
authentication  and  authorization  would  be  vitally  important,  not 
only  to  protect  the  apps  and  data  should  the  crew  misplace  the 
tablet  somewhere  outside  the  shop,  but  also  to  correctly  log 
who  accessed  the  apps  and  what  they  did  within  them. 

Data  Security  vs.  User  Experience 

Computer  security  is  a  balance  between  usability  and  protec¬ 
tion,  or  more  specifically  between  usability  and  cryptographic 
strength.  If  security  controls  are  too  demanding,  ample  evi¬ 
dence  suggests  users  will  circumvent  or  disable  the  controls. 

For  example,  most  users  select  insecure  passwords  easy  to 
remember  instead  of  strong  passwords  they  are  prone  to  forget. 
Smartphones  have  an  added  problem  in  small  screens  and  key¬ 
boards  that  make  typing  passwords  more  difficult  and  add  delay. 
Passwords  for  email  and  other  accounts  are  therefore  entered 


once  in  the  device  settings  and  stored,  even  when  the  device 
is  powered  off.  This  reduces  security  to  device  locking;  after  a 
device  is  unlocked,  the  user  has  immediate  access  to  password- 
protected  data  and  apps.  With  device  locking,  it  is  difficult  to 
guarantee  the  locking  implementation  is  secure.  The  Internet 
contains  numerous  methods  to  circumvent  device  locks. 

Smartphones  offer  the  potential  for  developing  new  methods 
of  authentication  using  sensors  such  as  the  touch  screen,  GPS, 
camera,  and  accelerometers.  Swipe  patterns  on  smartphones 
are  one  example;  others  include  picture  passwords,  tap  patterns, 
and  arm  motions.  Before  adopting  new  authentication  methods, 
there  should  be  a  formal  analysis  of  the  cryptographic  strength 
to  determine  the  number  of  pictures,  taps,  or  motions  required. 
The  critical  question  is  whether  new  methods  can  improve  us¬ 
ability  for  the  same  level  of  protection  as  traditional  methods. 
Consequently,  our  research  includes  a  study  to  determine  user- 
perceived  usability  as  a  function  of  cryptographic  strength. 

Another  novel  approach  to  authentication  is  to  apply  appli¬ 
cation-specific  constraints.  Imagine  a  field-deployable  app  for 
a  small  combat  unit,  which  provides  and  disseminates  mission 
information  across  the  unit.  The  information  is  highly  sensitive 
and  needs  protection  from  loss  of  the  device  in  the  battlefield, 
but  soldiers  in  battle  cannot  afford  to  repeatedly  authenticate. 

An  application-specific  constraint  could  be  realized  using 
GPS  where: 

a.  the  application  registers  as  a  member  of  the  unit’s 
device  group; 

b.  the  application  does  not  operate  if  it  is  located  more 
than  1 ,000  feet  from  another  registered  device;  and 

c.  the  application  automatically  uninstalls  and  erases  all  data 
if  accessed  outside  the  required  separation  distance. 

A  soldier  could  use  the  application  without  explicit  login  while 
protecting  data  if  the  device  was  found  or  captured.  Although 
hypothetical,  this  example  shows  how  device  sensors  can  be 
used  to  develop  new  application-level  security  controls. 

Ongoing  SwRI  research  is  focusing  on  the  use  of  mobile- 
device  capabilities  to  investigate  new  paradigms  for  application 
security  and  their  impact  on  user  experience.  Using  custom 
mobile  applications,  formal  cryptographic  analysis,  and  a  varied 
user  base,  this  research  is  shedding  light  on  how  applications 
and  data  can  be  secured  on  mobile  devices  with  minimal  impact 
on  usability. 

Summary 

Apple’s  iOS  model  provides  greater  security  out-of-the-box 
given  Apple’s  total  control  over  the  device,  the  app-development 
environment,  and  the  app-distribution  model.  Google’s  Android 
provides  greater  potential  for  application-level  security  due  to 
the  extensive  and  open  nature  of  the  SDK.  Neither  OS  model 
currently  provides  any  significant  focus  for  application-level  se¬ 
curity.  To  truly  allow  mobile  devices  to  replace  PCs  and  laptops, 
further  research  and  development  will  be  necessary  to  enable 
true  application  security  within  the  mobile-device  environment.^ 
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Engaging  the 
Community 

Strategies  for  Software 
Assurance  Curricula  Outreach 

Dr.  Carol  A.  Sledge,  Software  Engineering  Institute 

Abstract.  How  to  better  achieve  secure  and  correctly  functioning  software 
systems,  regardless  of  their  origins,  application  domain,  or  operational  environ¬ 
ments?  Engaging  a  knowledgeable  team  of  educators  to  develop  curricula, 
courses,  and  other  materials  for  the  discipline  of  software  assurance  is  but  the 
start.  If  we  build  it,  will  they  come?  In  this  paper,  I  explore  strategies  this  team 
of  educators  used  to  encourage  the  community  of  computing  educators  to 
adopt  software  assurance  curricula. 

Background 

Our  lives  and  our  world  depend  on  software.  Highly  complex, 
interdependent  software  systems  are  critical  to  virtually  every 
aspect  and  domain  of  society  today.  However  ubiquitous  soft¬ 
ware  has  become,  security  advances  have  not  been  commen¬ 
surate  with  the  vital  role  software  now  plays.  As  a  consequence, 
our  exposure  to  risk  is  ever  increasing. 

The  complexity  of  software  and  software-intensive  sys¬ 
tems  has  inherent  risk:  it  obscures  the  essential  intent  of  the 
software,  masks  potentially  harmful  uses,  precludes  exhaustive 
testing,  and  also  introduces  additional  problems  with  respect  to 
the  operation  and  maintenance  of  the  software.  The  interdepen¬ 
dence  of  these  systems  means  attackers  can  focus  on  the  most 
vulnerable  component  to  damage  the  larger  system(s),  while 
today’s  interconnectivity  makes  the  proliferation  of  malware 
easy,  but  the  identification  of  its  source  difficult  [1].  Threats  are 
large  and  diverse,  from  unsophisticated  opportunists  to  techni¬ 
cally  savvy  entities  backed  by  organized  crime  [2],  nation  states, 
and  similar  organizations  with  malicious  intent. 

Software  Assurance  Curriculum  Project 

Understanding  the  importance  of  the  software  assurance 
discipline  for  protecting  national  infrastructures  and  systems,  the 
DHS  National  Cyber  Security  Division  has  recognized  the  grow¬ 
ing  need  for  skilled  practitioners  in  this  area.  At  the  direction 
of  DHS,  researchers  in  SEI1  at  Carnegie  Mellon  University  de¬ 
veloped  the  Software  Assurance  Curriculum  Project  (SwACP). 
The  SwACP  development  team  is  composed  of  knowledgeable 
educators  from  a  number  of  institutions  of  higher  education,2 
who  collectively  have  substantial  background  in  software  as¬ 
surance  research,  software  engineering  research  and  practice, 


and  software  engineering  education  [3],  and  who  participate  in 
related  professional  society  curricula  development. 

What  is  software  assurance?  The  definition  used  by  the 
SwACP  team  is,  “Software  assurance  (SwA)  is  the  application 
of  technologies  and  processes  to  achieve  a  required  level  of 
confidence  that  software  systems  and  services  function  in  the 
intended  manner,  are  free  from  accidental  or  intentional  vulner¬ 
abilities,  provide  security  capabilities  appropriate  to  the  threat 
environment,  and  recover  from  intrusions  and  failures  [4].” 3  This 
is  a  slight  extension  of  the  Committee  on  National  Security 
Systems’  definition  [5]  used  by  our  DHS  sponsor. 

Many  colleges  and  universities  have  degree  programs  in 
areas  such  as  software  engineering  and  information  security, 
but  programs  and  tracks  in  software  assurance  are  lacking.  The 
work  of  the  SwACP  addresses  this  gap. 

The  focus  of  the  SwACP  is  to: 

•  Identify  a  core  body  of  knowledge  that  educational 
institutions  can  use  to  develop  Master  of  Software 
Assurance  (MSwA)  degree  programs 

•  Mentor  universities  in  developing  standalone  MSwA  degree 
programs  and  tracks  within  existing  software  engineering 
and  computer  science  master’s  degree  programs 

•  Promote  an  undergraduate  curriculum  specialization  for 
software  assurance 

•  Address  community  college  needs 

To  date  the  SwACP  team  has  produced  four  volumes4: 

•  Master  of  Software  Assurance  Reference  Curriculum5  [4] 

•  Undergraduate  Course  Outlines6  [6] 

•  Master  of  Software  Assurance  Course  Syllabi  [7] 

•  Community  College  Education7  [8] 

In  addition  to  these  reports,  the  team  also  developed  papers 
[1, 3,  9,10,  1 1],  presentations  [12,13],  and  workshops  [1 4]. 8 

Both  the  Association  for  Computing  Machinery  (ACM)  and 
the  IEEE  Computer  Society  (IEEE-CS)  have  recognized  the 
MSwA  Reference  Curriculum  as  appropriate  for  a  master’s 
program  in  software  assurance.  This  formal  recognition  signifies 
to  the  educational  community  that  the  MSwA  Reference  Cur¬ 
riculum  is  suitable  for  creating  graduate  programs  or  tracks  in 
software  assurance.9 

Outreach 

Defining  transition  strategies  for  future  implementation  of  the 
software  assurance  curricula  is  one  of  the  goals  of  the  SwACP. 
Many  SwACP  team  members  had  been  previously  involved  in 
curriculum  work  and  understood  the  need  to  have  a  compre¬ 
hensive  plan  for  promoting  the  transition  and  adoption  of  the 
various  curricula.  In  the  academic  world,  transition  is  a  lengthy 
process,  with  a  number  of  potential  barriers  to  adoption.  While 
introducing  one  new  elective  course  may  be  relatively  easy,  in¬ 
troducing  a  new  track  takes  significant  effort,  and  adding  a  new 
degree  program  is  a  real  challenge.  Many  barriers  exist:  insuf¬ 
ficient  interested  students  in  the  surrounding  geographic  area, 
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lack  of  qualified  faculty,  lack  of  administrative  support,  funding, 
etc.  For  the  SwACP  to  succeed,  a  comprehensive  outreach  and 
promotional  plan  was  needed. 

For  the  first  volume  produced,  the  MSwA  Reference  Cur¬ 
riculum,  planned  promotional  activities  targeting  educators 
included  [3]: 

•  Publicity-SwACP  team  members  disseminated  announce¬ 
ments,  press  releases,  and  flyers  regarding  the  team’s  work 
via  email,  websites,  educational  publications,  and  professional 
societies;  they  also  distributed  promotional  materials  to  col¬ 
leagues  when  they  attended  conferences. 

•  Software  assurance  education  discussion  group-We 
established  a  Linkedln  discussion  group  in  which  faculty  inter¬ 
ested  in  implementing  all  or  portions  of  the  curriculum  could 
interact  with  the  team  and  other  colleagues  who  are  using 
the  curriculum. 

•  Awareness-Team  members  conducted  and  videotaped10 
an  awareness-raising  faculty  workshop  at  the  Conference  on 
Software  Engineering  Education  and  Training  (CSEET)  2010 
[1 4].  This  workshop  was  among  the  various  presentations 
given  at  faculty  and  curriculum  development  venues.  Addition¬ 
ally  an  overview  podcast  was  produced,  including  a  discussion 
of  what  students  and  employers  can  expect.11 

•  Mentoring-The  SwACP  team  is  mentoring  universities 
and  faculty  members  who  wish  to  offer  a  course,  track,  or 
MSwA  degree  program.  This  support  includes  review  of  imple¬ 
mentation  plans  and  course  outlines  and  advice  on  references 
and  other  materials. 

•  Publication-SwACP  team  members  have  written  papers 
and  given  talks  on  the  curriculum. 

•  Professional  society  recog nition-As  mentioned  previously,  both 
ACM  and  IEEE-CS  officially  recognize  the  MSwA  curriculum. 

For  transition  and  promotion  of  the  MSwA  Reference  Curricu¬ 
lum,  early  adoption  is  important.  The  Stevens  Institute  of  Technol¬ 
ogy,  home  of  one  of  the  SwACP  team  members,  was  the  first 
school  to  adopt  elements  of  the  curriculum:  it  has  developed  two 
tracks  in  software  assurance  within  its  Master  of  Science  in  Soft¬ 
ware  Engineering  program.  One  track  is  for  students  who  antici¬ 
pate  a  career  in  secure  software  development,  while  the  other  is 
for  students  interested  in  acquisition  and  management  of  trusted 
software  systems.  For  those  students  who  already  have  an  ad¬ 
vanced  degree  or  who  are  not  ready  to  commit  to  a  full  graduate 
program,  graduate  certificates  are  available  [3]. 12  Consideration 
and  plans  for  adoption  of  courses  and  tracks  are  underway  at  the 
universities  of  the  team  members,  as  well  as  other  schools. 

Outreach:  Leverage  and  Trust 

For  the  MSwA  curriculum  transition  and  promotion  goal,  all 
planned  activities  were  successfully  completed  and  continue 
to  be  pursued.  Long  term,  a  key  point  of  leverage  is  the  con¬ 
tinued  participation  by  SwACP  team  members  in  reviewing 
and  updating  professional  society  curriculum  guidelines.  For 
example,  SwACP  team  member  Mark  Ardis  is  the  chair  of  the 


Software  Engineering  2004  Review  Task  Force,  a  joint  effort 
of  the  ACM  and  the  IEEE-CS.  This  task  force  has  collected 
comments  from  the  software  engineering  community  about 
the  need  to  update  Software  Engineering  2004,  the  recom¬ 
mended  guidelines  for  undergraduate  software  engineering 
education.  Ardis  noted  that  several  reviewers  had  com¬ 
mented  on  the  need  for  more  material  on  software  security 
and  assurance.  SwACP  team  member  Elizabeth  Hawthorne 
is  chair  of  the  ACM  Committee  for  Computing  Education 
in  Community  Colleges  and  is  also  a  member  of  the  ACM 
delegation  to  the  Steering  Committee  of  the  joint  ACM  and 
IEEE-CS  Computing  Curriculum:  Computer  Science  201  3, 13 
an  effort  in  its  planning  stages  focused  on  international  cur¬ 
ricular  guidelines  for  undergraduate  programs  in  computing. 
She  reported  that  one  new  knowledge  area  under  consider¬ 
ation  is  dedicated  to  “computer  security”  (called  Information 
Assurance  and  Security).14  Through  these  relationships,  the 
SwACP  team  can  stay  updated  and  engaged  with  current 
curricula  development  efforts  and  seek  ways  to  leverage  the 
curricula  the  team  developed  in  graduate,  undergraduate,  and 
community  college  programs. 

In  the  short  term,  the  need  for  quick  educational  community 
feedback  on  draft  SwACP  documents  and  for  broader  aware¬ 
ness  and  involvement  suggested  a  focused  leveraging  of  trusted, 
personal  relationships,  in  addition  to  the  promotion  and  transition 
mechanisms  already  cited.  Specifically,  I  was  tasked  with  extend¬ 
ing  the  SwACP  team’s  ongoing  efforts  to  faculty  and  entities 
whom  I  knew  to  be  involved  in  course,  resource,  and  curriculum 
development  for  software  engineering,  information  systems,  infor¬ 
mation  assurance,  computer  science,  information  security,  etc.  at 
the  master’s,  undergraduate,  and  community  college  levels.  By  no 
means  was  this  complete  coverage,  but  the  trusted  relationships 
increased  the  likelihood  that  faculty  would  engage  (and  redistrib¬ 
ute  the  information).  Utilizing  relationships  with  other  colleagues, 
appropriate  faculty  at,  for  example,  the  U.S.  Service  Academies, 
were  specifically  targeted  via  a  trusted  intermediary. 

Targeted  faculty  included15: 

•  Past  participants  in  the  National  Science  Foundation  (NSF)- 
funded  Information  Assurance  Capacity  Building  Program  at 
Carnegie  Mellon  University 

•  Principal  investigators  of  the  15  NSF-funded  Advanced 
Technological  Education  (ATE)  Centers  and  through  the  NSF 
ATE  program  manager  to  other  NSF  program  managers 

•  Those  at  1 7  NSA/DHS  Centers  of  Academic  Excellence  in 
IA  Education  (CAE/IA)  and  CAE-Research  (CAE-R) 
programs16 

•  California  State  University  Discipline  Council  (department 
heads  of  computer  science,  information  science/information 
systems,  and  software  engineering  at  the  23  schools  that  make 
up  the  council) 

•  Participants  in  the  educational  outreach  and  curriculum 
development  activities  and  members  of  the  NSF  Science  and 
Technology  Center  Team  for  Research  in  Ubiquitous  Secure 
Technologies17 
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•  Members  of  the  Association  of  Computer/Information  Sci¬ 
ences  and  Engineering  Departments  at  Minority  Institutions18 

•  Members  of  various  faculty  email  lists,  including  personal 
lists  of  faculty  in  related  disciplines  interested  in  course  and  cur¬ 
riculum  development,  and  those  working  on  articulation  agree¬ 
ments  with  community  colleges 

•  U.S.  service  academies  and  postgraduate  schools19 

Over  the  years,  faculty  from  these  entities  formed  collab¬ 
orative  relationships  to  create,  adapt,  adopt,  and  share  new 
materials  as  appropriate  for  their  departments  and  prospective 
students,  as  well  as  for  others.  Given  their  interest  in  related 
disciplines,  these  communities  of  interest  were  prime  targets  for 
our  outreach  effort. 

In  addition  to  faculty  and  academic  institutions,  it  was  important 
to  leverage  related  government  and  practitioner  efforts.  Collabo¬ 
rating  with  organizations  in  the  DoD  and  NIST,  the  DHS  National 
Cyber  Security  Division  Software  Assurance  (SwA)  Program  co¬ 
sponsors  the  Software  Assurance  Community.  In  this  community, 
members  of  government,  industry,  and  academia  come  together 
to  discuss,  develop,  and  implement  software  security  practices, 
methodologies,  and  technologies  in  forums  and  working  groups.20 
Because  of  SwACP  team  member  participation  in  this  community, 
the  1 5th  semi-annual  SwA  Forum  in  September  201 1  examined  the 
implications  of  trends  and  emerging  factors  in  training  and  educa¬ 
tion  for  software  assurance  workers.  The  NIST  National  Initiative 
for  Cybersecurity  Education  (NICE)  has  a  goal  to  “bolster  formal 
cybersecurity  education  programs  encompassing  kindergarten 
through  1 2th  grade,  higher  education  and  vocational  programs.”21  At 
the  December  201 1  DHS  Working  Group  meeting,  co-chaired  by 
the  SwACP  team  lead,  Nancy  Mead,  the  alignment  with  NICE  was 
discussed. 

Outreach  Outcomes 

From  the  beginning,  the  SwACP  recognized  the  importance 
of  transition  strategies  for  the  implementation  of  the  software 
assurance  curricula,  including  the  ongoing  promotion  of  the  cur¬ 
riculum  work  and  outreach  to  the  various  communities  of  interest 
to  encourage  them  to  participate.  Given  the  time  constraints,  the 
various  educational  levels  addressed,  and  potential  constituencies 
involved,  multiple  people  and  entities  employed  multiple  outreach 
mechanisms,  coordinating  where  possible  with  related  efforts. 

Challenges  to  our  outreach  effort  include  the  usual  potential 
barriers  to  adoption  of  courses,  tracks,  and  curricula,  including  the 
time  and  resources  needed,  especially  in  light  of  sometimes-severe 
funding  cuts  in  departments.  Another  challenge  was  the  alignment 
and  timing  regarding  revision  cycles  of  both  departmental  and  the 
related  professional  curriculum  development  efforts. 

Outreach  mechanisms  that  are  proving  effective  include: 

•  The  Build  Security  In  website,  sponsored  by  DHS,  and  the 
SEI  MSwA  website 

•  Ongoing  SwACP  team  member  participation  (previously  and 
currently)  with  professional  curricula  development  activities 

•  Papers  and  presentations  at  appropriate  educator  confer¬ 
ences  and  workshops 

•  Leveraging  trusted  relationships  with  educators  in  related 


disciplines  to  increase  the  likelihood  of  engagement  and  dis¬ 
semination  (to  other  interested  faculty)  of  information  related  to 
SwA  curricula  and  content. 

One  example  of  successfully  leveraging  trusted  relationships 
with  educators  is  the  Department  of  Computer  Science  at  the 
U.S.  Air  Force  Academy.  They  recently  undertook  a  curriculum 
review  that  defined  multiple  cross-curricular  initiatives  to  support 
program  outcomes,  including  “secure  programming”  (security 
and  software  assurance)  [15].  Among  the  resources  used  was 
the  Undergraduate  Course  Outlines  [6].  They  are  also  consider¬ 
ing  the  development  of  some  undergraduate  course  exercises 
and  projects  that  focus  on  secure  coding  and  software  assur¬ 
ance,  to  be  incorporated  into  existing  undergraduate  courses 
as  a  means  to  integrate  these  topics  as  “natural  and  normal 
practices  inherent  to  software  development."22 

Faculty  and  educators  have  contacted  the  SwACP  team  lead 
for  information  about  how  to  build  a  BS  or  MS  program  with  an 
SwA  concentration 23  One  department  at  the  University  of  Hous¬ 
ton  has  adopted  significant  portions  of  the  software  assurance 
curriculum  in  their  program  by  incorporating  elements  in  several 
courses,  where  appropriate,  with  the  majority  in  focus  courses 
(two  each  in  the  undergraduate  and  graduate  programs).24 

Other  outreach  mechanisms  are  early  in  their  respective  cycles 
or  require  more  of  a  critical  mass  to  be  effective.  For  example, 
the  Software  Assurance  Education  discussion  group  on  Linkedln 
provides  a  forum  for  faculty  to  share  problems  and  experiences 
in  teaching  software  assurance  courses.  As  more  educators 
incorporate  software  assurance  topics,  modules,  and  courses  into 
their  departmental  programs,  we  hope  they  will  utilize  this  forum. 
Ongoing  participation  in  the  related  government  and  practitioner 
efforts  will  help  with  the  alignment  and  leveraging  of  these  activi¬ 
ties,  with  the  common  goal  to  increase  awareness,  participation, 
and  adoption  of  appropriate  software  assurance  practices. 

Summary 

The  SwACP  team  feels  that  software  assurance  education  at 
all  levels  is  essential  to  ensure  that  software  and  software-inten¬ 
sive  systems  are  developed  with  assurance  in  mind  [1 1].  While 
software  assurance  supports  and  complements  the  educational 
objectives  of  a  software  engineering  program,  it  also  supports 
and  complements  the  educational  objectives  of  related  disciplines 
such  as  computer  science  and  information  systems.  Engaging 
knowledgeable  educators  experienced  in  related  curriculum 
development  to  produce  software  assurance  curricula  and  related 
materials  is  but  one  part  of  this  DHS-funded  effort.  Multiple 
mechanisms  must  be  continually  utilized  to  reach  the  various 
educator  communities  to  increase  awareness,  encourage  partici¬ 
pation,  and  ultimately  adopt  software  assurance  topics,  courses, 
tracks,  and  curricula.  Certain  outreach  strategies  have  proved  to 
be  successful  in  the  relatively  short  time  the  SwACP  has  been  in 
existence.  Leveraging  professional  curricula  development  entities, 
as  well  as  alignment  with  related  government  efforts,  while  longer 
term,  should  provide  the  foundation  for  sustainment.^ 
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Engineering  program. 

6.  This  set  of  outlines  includes  seven  course  descriptions  that  could  be  included  in  a  software 
assurance  specialization  track  of  a  traditional  computer  science  degree  program.  To  provide  an 
emphasis  on  software  assurance  topics  in  the  first  year  of  a  curriculum,  descriptions  of 
alternative  forms  of  Computer  Science  I  and  II  are  included. 

7.  The  ACM  Committee  for  Computing  Education  in  Community  Colleges  (<www.acmccecc. 
org>),  led  by  Elizabeth  Hawthorne,  partnered  with  the  SwACP  to  produce  this  volume  that 
includes  discussion  of  existing  curricula  related  to  software  security  that  are  suitable  for 
community  colleges.  The  target  audiences  are  students  planning  to  transfer  to  a  four-year 
program  and  students  with  prior  undergraduate  technical  degrees  who  wish  to  become  more 
specialized  in  software  assurance.  The  report  includes  course  outlines  and  identification  of  resources. 

8.  These  are  just  a  few  of  the  papers  and  presentations.  Reference  [1  ]  provides  the  best  overview 
of  the  SwACP,  while  reference  [11]  provides  a  much  briefer  synopsis,  including  those  artifacts, 
foundational  materials,  and  recent  curriculum  guidelines  referenced  in  the  development  of  the 
SwACP  curricula. 

9.  The  ACM  and  its  partner,  the  IEEE-CS,  have  developed  several  computing  curricula  and  are 
community  leaders  in  curricula  development. 

10.  The  CSEET  2010  three  hour  workshop  is  available  at  <https//www.vte.certorg/vteweb/ 
RequestAccess/  ClassPreview.aspx?Classid=1 20> 

11 .  Podcast  is  available  at  <http  ^  /www.cert org/podcast/show/201 01 026m ead.html> 

1 2.  The  environment  that  allowed  SIT  to  quickly  create  its  software  assurance  program,  as  well  as 
potential  adaptations  of  the  MSwA  curriculum  for  information  systems  curricula  are  also 
described  in  [3]. 

13.  <www.cs2013.org> 

14.  A  recent  addition  to  the  SwACP,  Remzi  Seker,  University  of  Arkansas,  Little  Rock,  is  a  member  of 
the  IEEE-CS  delegation. 

15.  In  addition  to  those  targeted  by  other  team  members  and  means,  this  outreach  effort  included 
faculty  and  educational  institutions  granting  masters,  bachelor’s,  and  associates’  degrees  in  21 
states  and  the  District  of  Columbia. 

16.  <http//www.nsa.gov/ia/academic_outreach/nat_cae/index.shtml> 

17.  <http://www.truststc.org/> 

18.  <http://www.admiusa.org/> 

19.  U.S.  Air  Force  Academy,  U.S.  Military  Academy,  U.S.  Naval  Academy,  Air  Force  Institute  of 
Technology,  Naval  Postgraduate  School,  U.S.  Naval  War  College,  and  U.S.  Coast  Guard  Academy 

20.  Information  about  SwA  Community  activities  including  forums  and  working  groups  can  be  found 
at  <https://buildsecurityin.us-cert.gov/swa/fomms.htm>;  see  especially  the  Workforce 
Education  and  Training  Working  Group. 

21 .  <http//csrc.nist.gov/nice/aboutUs.htm> 

22.  Communication  to  Carol  Sledge  by  Dr.  Steve  Hadfield,  Associate  Professor  and  Curriculum  Chair, 
Department  of  Computer  Science,  U.S.  Air  Force  Academy 

23.  These  include  Hampton  University,  TRUST,  Gunter  Air  Force  Base,  Southeast  Missouri  State 
University,  Cleveland  State  University,  and  University  of  Detroit  Mercy. 

24.  Communication  to  Nancy  Mead  by  Wm.  Arthur  Conklin  of  the  Department  of  Information  and 
Logistics  Technology 


CrossTalk-March/April  2012  21 


SECURING  A  MOBILE  WORLD 


The  PC  Evolution 
and  Diaspora 

James  A.  Sena,  Ph.D.,  California  Polytechnic  State  University 

Abstract.  This  paper  examines  the  development,  evolution,  and  diaspora  of 
the  personal  computer.  An  overview  of  the  Innovation  Diffusion  Technology 
(IDT)  model  is  presented.  Using  this  as  a  framework,  the  personal  computer  is 
categorized  from  multiple  perspectives.  The  direction,  durability,  and  mutations 
(the  diaspora)  of  the  personal  computer  are  presented  using  Ansoff’s  model 
of  diversification. 

Introduction 

In  August  of  201  1  Hewlett  Packard,  the  world’s  largest 
seller  of  PCs,  confirmed  it  was  looking  to  sell  off  its  personal 
computing  business-possibly  getting  out  of  the  hardware 
game  altogether  and  dropping  its  tablet  and  smartphone  op¬ 
erations  as  well.  This  event  along  with  IBM’s  decision  in  2004 
to  sell  its  PC  business  line  to  Lenovo,  a  China-based  firm,  is  a 
harbinger  that  the  low-margin  PC  business  may  not  be  worth 
pursuing.  Concurrently  the  rise  of  alternatives  to  traditional 
PCs,  the  tablet(s),  continues  unabated-with  forecasts  through 
201  1  at  60  million  tablets  and  in  201  2  to  be  90  million  units 
[1].  There  still  will  be  over  100  million  PCs  sold  worldwide  for 
several  years  because  people  need  them  for  certain  tasks  [2]. 
Many  of  the  habits  we  associate  with  personal  computers  can 
be  carried  out  with  touchscreen  and  an  Internet  connection- 
done  anywhere,  and  quickly.  The  iPhone  has  demonstrated 
what  could  be  done  with  a  relatively  small  device  that  could 
single  task  very  well.  With  Android  and  Apple  netbooks  being 
circulated,  this  idea  of  a  small,  relatively  inexpensive  device 
connected  to  back-end  services  is  the  leading  edge  of  a 
paradigm-shifting  platform— along  with  the  application  layer  in 
the  private  cloud  [3]. 

According  to  Brodkin  [4],  “since  the  personal  computer 
debuted  in  1971,  a  Darwin-esque  evolution  process  has  lifted 
the  PC  from  modest  beginnings  to  its  prevailing  role  as  an 
indispensable  part  of  life  in  the  21st  century”  ...  “evolving  from 
clunky  commercial  flops  to  slick,  high-powered  machines  that 
play  a  vital  role  in  our  daily  lives,  both  for  work  and  play.”  Per¬ 
sonal  computers  have  been  the  technology  engine  drivers  from 
Intel  to  Microsoft  to  Dell  to  HP  to  Google  to  Facebook.  But  the 
rise  of  mobile  computing  is  upending  the  technology  business 
and  is  simultaneously  redefining  what  is  a  personal  computer 
and  how  we  use  it  [1 , 5]. 

This  paper  is  a  sector  case  study  that  seeks  to  examine 
the  development,  evolution,  and  diaspora  of  the  personal 
computer.  The  remainder  of  this  paper  proceeds  as  follows. 
First,  we  present  an  overview  of  the  IDT  model  and  discuss 
innovation  characteristics.  Then  we  categorize  the  personal 
computer  from  multiple  perspectives  using  this  as  a  frame¬ 
work.  Finally,  we  comment  on  the  direction,  durability,  and 
mutations  (the  diaspora)  of  the  personal  computer  using 
Ansoff’s  model  of  diversification. 


Overview  of  Diffusion  of  Innovation 

Diffusion  of  innovation  theory  [6]  describes  the  process 
through  which  new  ideas,  practices,  or  technologies  are  spread 
into  a  social  system.  According  to  Murray  [7],  diffusion  of  in¬ 
novation  theory  holds  that  innovation  diffusion  is  a  general 
process,  not  bound  by  the  type  of  innovation  studied,  by  who 
the  adopters  are,  or  by  place  or  culture,  such  that  the  process 
through  which  an  innovation  becomes  diffused  has  universal 
applications  to  all  fields  that  develop  innovations.  Diffusion  is 
defined  as  the  process  in  which  an  innovation  is  communicated 
through  certain  channels  over  time  among  the  members  of  a 
social  system.  Innovation  is  an  idea,  practice,  or  object  that  is 
perceived  as  new  by  an  individual  or  other  unit  of  adoption.  In 
addition,  innovation  also  does  not  necessarily  mean  better  or 
that  the  new  idea  is  more  beneficial  to  an  individual.  Whereas  in¬ 
novation  can  refer  to  something  abstract,  like  an  idea,  it  can  also 
be  concrete,  like  a  new  piece  of  technology.  This  article  focuses 
specifically  on  the  personal  computer  as  a  particular  type  of 
innovation  of  interest. 

Rogers  [6,  8]  suggested  that  there  were/are  four  main 
elements  in  the  diffusion  process: 

•  The  innovation 

•  The  communication  channels  through  which  the  innovation 
is  diffused 

•  Time 

•  The  social  system 

The  end  results  [9]  of  diffusion  are  adoption,  implementation, 
and  institutionalization.  Diffusion  researchers  across  many  aca¬ 
demic  disciplines  have  identified  a  consistent  process  through 
which  innovations  are  diffused  into  social  systems.  There  is  gen¬ 
erally  a  period  of  slow  growth,  followed  by  more  rapid  expansion, 
followed  ultimately  by  a  plateau  or  another  slow  growth  period. 
Different  characteristics  of  the  innovation,  communication  chan¬ 
nels,  and  social  system  are  likely  to  have  varying  influences  at 
different  times  throughout  the  diffusion  process  [10]. 

Individuals  vary  in  their  willingness  to  accept  new  ideas  and 
change  [11].  Rogers  [6]  classified  adopters  into  the  following 
five  categories  on  the  basis  of  their  rates  of  adoption: 

•  Innovators,  who  are  among  the  first  2.5%  in  the  population  to 
adopt  the  innovation  and  demonstrate  an  adventurous, 
cosmopolite  nature. 

•  Early  adopters,  who  fall  into  the  next  1 3.5%  of  adopters  and 
who  are  integrated  closely  into  the  social  network  and  are 
often  opinion  leaders. 

•  The  early  majority,  who  are  the  next  34%  of  adopters  and  are 
described  as  deliberate  followers. 

•  The  late  majority,  the  next  34%  who  are  often  skeptical  of  the 
innovation  at  first  but  eventually  succumb  to  peer  pressure. 

•  Laggards,  who  are  the  final  1 6%  and  who  tend  to  be  more 
traditional  and  isolated  compared  with  earlier  adopters. 
Individuals  who  are  among  the  last  to  adopt  an  innovation 
often  exhibit  the  longest  decision-making  processes  prior 
to  deciding. 
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Figure  1 .  Drivers  of  Growth  for  the  PC 


Marketing  of  the  PC 

The  PC  did  not  magically  appear  in  its  current  wide-screen, 
multi-core,  viewing  form  overnight.  It  took  many  years  to  evolve 
from  the  IBM  PC  of  1981  to  the  high-powered  tech  gadgets. 
The  original  idea  of  the  PC  was  sound:  using  off  the  shelf  parts 
combined  with  a  relatively  open,  but  curated  set  of  standards  to 
avoid  reinventing  from  one  version  of  the  PC  to  the  next.  There 
are  a  number  of  milestones  passed  along  the  way,  from  the 
introduction  of  the  IBM  PC  in  August  1981,  and  moving  on  to 
the  appearance  of  the  first  PC  clones  in  1 982,  leading  to  the 
“post-PC”  tablets  of  2010-201 1.  Microsoft,  AMD,  and  Intel  have 
outplayed  and  outlasted  their  rivals.  Plus,  many  of  the  hundreds 
of  “PC  clone  makers”  have  either  been  left  by  the  wayside,  or 
have  been  absorbed  into  larger  conglomerates.  Apple  has  been 
friend,  rival,  and  self-appointed  nemesis  during  this  period,  and 
without  that  competition,  it  is  unlikely  that  we  would  see  the 
technology  move  in  the  directions  it  has.  There  are  an  abun¬ 
dance  of  time-lines  and  papers  addressing  the  evolution  and 
eras  of  the  PC.  We  have  constructed  a  time-line  fitted  to  the 
IDT  curve-products,  and  way  stations  in  the  journey  through  PC 
technology  are  depicted.  Our  intention  was  not  to  be  exhaustive 
but  to  cite  major  events  as  well  as  game-changing/legitimizing 
turning  points.  The  time-line  is  shown  in  Figure  1 . 

The  first  key  event  in  the  PC  era  was  the  introduction  of  the  IBM 
PC.  IBM  dominated  the  computer  industry  during  the  pre-computer 
era  (machine-accounting);  championed  the  many  generations  of 
mainframes  (e.g.  the  360  -  370);  operating  systems  and  most 
other  software  applications;  extended  and  expanded  the  minicom¬ 
puter  industry  (System  32,  34,  36,  38. . .)  and  then  entered  into 
the  PC  arena  on  a  major  scale-setting  a  standard  for  operating 
systems  and  controlling  the  overall  market  in  its  initial  stages.  These 
were  the  “early  adopters”— primarily  computer  professionals  that 
transitioned  from  the  mainframe  to  the  minicomputer.  Many  users 
experienced  the  computer  as  a  stand-alone,  special-purpose  desk¬ 
top  (e.g  the  graphics  machines  created  by  HP). 


The  PC  at  this  point  was  a  computer  without  a  clear  pur- 
pose-the  accompanying  event  was  the  spreads  heet-Visi- 
Calc-followed  closely  by  Lotus  1 23.  Abruptly  businesses  and 
the  general  computer  population  had  a  tool  that  legitimized  the 
PC.  Simultaneously  word  processors  and  database  managers 
were  introduced  and  followed  by  graphic/presentation  software. 
The  speed,  storage  capacity  and  communication  channels  still 
were  lacking.  General  business  users  and  professionals  began 
to  use  the  PC  for  individual  and  departmental  applications  and 
analysis  -they  formed  the  nucleus  of  the  “early  adopters.”  At  this 
juncture  in  time  problems  arose  in  many  businesses  and  govern¬ 
ment  agencies  -  the  IT  administration  did  not  want  to  relinquish 
control  to  the  end  users. 

As  hardware  enhancements  and  network  connections  were 
introduced  the  capabilities  of  the  PC  made  possible  the  use  of 
the  graphical  user  interface-obsoleting  the  use  of  the  PC  as 
a  terminal  to  the  mainframe.  This  marked  the  rise  of  Microsoft 
not  only  as  a  provider  of  operating  systems  but  also  the  visual 
aspects  of  Windows  3  and  the  business  acumen  of  Microsoft 
Office-the  suite  of  products  for  the  business  at  the  individual 
and  department  level.  As  hardware  technology  enabled  more 
elaborate  software  and  system  use  the  PC  became  a  standard 
within  most  businesses— the  “early  majority”  embraced  the  PC 
as  their  primary  desktop  tool  for  basic  tasks  along  all  levels  of 
business  activity. 

Closely  following  these  enhancements  was  the  introduction  of 
the  World  Wide  Web  [WWW]  browser  as  an  overlay  over  the  Inter¬ 
net.  Prior  to  this  introduction  the  Internet  existed  for  an  extended 
period  but  did  not  have  wide-spread  use  except  at  the  busi¬ 
ness  level  for  file  transfers  and  email-type  commerce.  Netscape 
was  the  killer  app  that  started  the  paradigm  shift-followed  by 
Microsoft’s  Internet  Explorer.  In  effect,  the  PC  became  the  vehicle 
for  every  man  to  communicate  -  no  longer  just  a  business-level 
system.  This  marked  the  peak  of  the  PC  era  and  the  diffusion  of 
PC  use  to  the  general  public — “the  majority”.  Not  only  was  the  PC 
the  inherent  tool  in  the  office  but  also  the  home  and  school. 
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New  Products 
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Related  Technology  | 

1  Unrelated  Technology 

Markets/Mission 

Horizontal  Diversification 

Same 

Barnes  &  Noble  -  Amazon 

Google  -  Samsung  -  HP  Slate  —  Intel  Ultrabook 

Type 

-  Sale  of  books  for  eReaders 

-  Enter  tablet  market 

Barnes  &  Noble  —  Amazon  Kindle  and  Tablet 

Apple  iPad  &  iPod  -  and  Android 

—  Software  for  PCs  &  other  devices 

-  sale/use  of  Books,  pdfs,  music,  video  as  Aps 

Google  -  Amazon  -  HP  Cloud  Computing 

-  Aps  for  Business  (~  office  tools) 

-  offer  services  to  existing  customers 

-Aps  for  Games,  Personal  Use 

Microsoft  Cloud  Computing 

-  Aps  for  alternative  Media  (Newspapers, etc) 

-  Office  365 

-  Windows  8 

Vertical  Integration 

Firm  its 

Amazon  is  able  to  use  its  web-based  ordering  and 

Google's 

own  customer 

electronic  distribution  system  without  incurring  additional 

-  Commitment  to  digitize  most  books  in  the 

costs 

public  domain  provides  a  ready  audience  for 
ereading  devices  and  other  medium 

Microsoft,  Google  use  products  internally  as 

-  Use  of  network  infrastructure  created  for 

development  tools  for  new/revised  products 

search  engine  as  competitive  alternative  for 

-  Online  office  products 

-  Social  networks  (Google  +) 

Publishers  can  partner  with  Amazon  and  Barnes  &  Noble 
distribution  and  other  supply  chain  capabilities 

Table  1.  Horizontal  and  Vertical  Integration 

The  culminating  event  was  the  rise  of  the  networks— the  local 
area  networks  in  businesses  and  later  in  homes— but  also  the  wide 
area  networks  for  businesses  and  ultimately  the  utilization  of  the 
complex  already  in  place,  the  Internet  The  operating  system  and 
router/switch  defined  by  Cisco  became  the  vehicle  for  communica¬ 
tion  worldwide.  That  combined  with  the  browser  enabled  access 
for  business  and  the  general  public  (“the  late  majority”).  Of  note 
the  browser  became  the  basic  user  interface  for  many  businesses 
and  government  agencies— the  U.S.  Navy  mandated  that  Internet 
Explorer  be  the  standard  interface  for  most  contractor  software 
development.  Following  this  accessibility  the  introduction  of  the 
search  engine  (Yahoo  and  then  Google)  made  the  web  a  perva¬ 
sive  tool.  And  lastly  the  social  networks  (MySpace  and  Facebook) 
involved  an  extensive  array  of  the  population  as  participants. 

At  the  beginning  of  the  1 990s  the  stability  of  the  personal 
computer  structure  and  industry  changed.  IBM  dominance  of 
the  PC  industry  and  its  role  as  standard-bearer  started  to  erode 
in  the  late  1 980s.  By  the  early  1 990s  the  market  structure  was 
one  in  which  a  number  of  firms  possessed  the  capability  to  supply 
interoperable  components.  Throughout  the  1 990s  and  beyond, 
thousands  of  manufacturers  built  PCs  around  hardware  and  soft¬ 
ware  components  mainly  supplied  by  Microsoft  and  Intel.  There 
are  two  distinct  types  of  supplier  to  the  PC  industry.  The  first 
type  supplies  components  such  as  disk  drives,  RAM,  peripherals 
etc.  Products  in  this  category  are  available  from  a  wide  variety  of 
sources  at  highly  competitive  prices.  The  other  type  of  supplier 
provides  products-most  notably  CPUs  and  operating  systems- 
available  from  just  a  few  sources  .i.e.  Microsoft  and  Intel. 

Most  firms  outsourced  the  production  of  components  manufac¬ 
turing  contractors  carrying  out  simple  manufacturing  operations  at 
high-volume  plants  in  low-cost  locations.  Eventually,  these  contrac¬ 
tors  took  on  more  complex  tasks,  such  as  design  and  testing.  By 
the  beginning  of  this  century,  large  contract  manufacturers  began 
to  build  entire  PCs  for  brand-name  companies,  designing  and  as¬ 
sembling  basic  computers  in  Asia  and  shipping  them  to  geographic 
hubs  for  production  to  be  completed.  These  full-line  distributors 
dominated  the  industry  with  the  broadest  customer  and  product 
base.  Many  PC  manufacturers  aimed  to  streamline  their  operations 
by  moving  from  a  build-to-stock  to  a  build-to-order  model.  Reduced 
inventory  led  to  reduced  costs. 
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The  four  main  types  of  PC  buyer  have  remained  the  same  since 
the  early  1990s.  Namely:  business,  home,  government,  and  educa¬ 
tion.  However,  the  distribution  channels  have  changed.  Business 
buyers  now  buy  direct  from  vendors  or  distributors  as  opposed  to  full- 
service  dealers.  Consumer  markets  are  serviced  by  web-based  retail¬ 
ers  that  can  service  all  types  of  demand  often  at  steep  discounts. 

In  a  survey  conducted  by  eWeek,  one  in  five  U.S.  adults  surveyed 
said  they  planned  to  own  a  tablet  by  201 4.  The  survey  included  ap¬ 
plication  use  on  tablets,  including  the  iPad  and  machines/tablets  based 
on  Google’s  Android  platform.  Some  78%  of  respondents  said  they 
planned  to  use  their  tablets  to  surf  the  Web.  Three-quarters  of  people 
said  they  would  use  their  machines  for  e-mail.  Other  uses  include 
electronic  reading  of  books  and  newspapers,  (53%),  social  networking 
(50%),  consuming  TV  and  other  apps  (43%).  Tablet  use  is  attractive 
for  enterprises  as  well,  with  37%  of  respondents  planning  to  use  their 
machines  for  business  concerns.  The  use  of  the  term  “laggard”  is  prob¬ 
ably  not  appropriately  used  in  this  presentation  of  the  PC  diffusion-an- 
other  interpretation  would  be  the  deployment  of  the  basic  technology 
and  ideas  rooted  in  the  PC  as  it  evolved  from  a  desktop  to  a  laptop  and 
currently  the  variety  of  devices  that  make  use  of  and  expand  on  the  PC 
platform-the  tablets,  the  smartphones  and  even  the  virtual  PC. 

Diversification-the  Diaspora 

Diversification  is  the  name  given  to  the  growth  strategy 
where  a  business  markets  new  products  in  new  markets.  For 
a  business  to  adopt  a  diversification  strategy  it  must  have  a 
clear  idea  about  what  it  expects  to  gain  from  the  strategy  and 
a  clear  assessment  of  the  risks.  Diversification  in  new  markets 
concerns  the  inclusion  of  activities  other  than  those  directly 
relating  to  the  product  or  associated  services.  There  are  four 
underlying  reasons  why  companies  diversify  [1  2]: 

•  When  their  objectives  can  no  longer  be  met  within  the 
product-market  scope  defined  by  expansion-even  if 
attractive  expansion  opportunities  are  still  available  and  past 
objectives  are  being  met,  a  firm  may  diversify  because  the 
retained  cash  exceeds  the  total  expansion  needs.  (The 
pressure  may  be  on  the  firm  to  invest  money  more  profitably.) 

•  When  diversification  opportunities  promise  greater 
profitability  than  expansion  opportunities.  This  may  occur 
under  several  conditions. 
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New  Products 

New  Markets/Mission 

Similar  Types 

New  Types 

Marketing  &  Technology 

Amazon  eReader  has  capabilites  for  reading  not 

A  number  of  new  technologies  for  tablets  are  being 

Related 

offered  by  any  other  device 

Apple  --  iPad 

-  Apple's  B2B  volume  purchasing  agreement 

Gaming  Industry--  companies  will  be  pressed  harder 
and  harder  to  come  up  with  new  ideas,  which  could 
make  for  an  uphill  battle  (Caron,  2009) 

applied  and  used  for  business  applications 

-  PC  manufacturers  are  designing  Hybrid 

Tablet  PCs  able  to  perform  heavy  duty  work 

Cloud  Services  -high  cost  of  power  and  space  is  going 
to  force  the  IT  world  to  look  at  cloud  services,  with  a  shift 
to  computing  as  a  cloud  resource  (lnfoworld,2008) 

Consumers  can  now  use  smaller  gadgets  to  do  many  of 
the  same  things  they  once  did  with  PCs,  such  as  surfing 
the  Internet,  storing  photos  and  sending  e-mail. 
(Robertson,  2011) 

Mobile  Workers  and  related  products 

-  Telecommuting  -  the  home  office 

-  Pressure  to  provide  tools  and  access  to 
corporate  system 

Marketing 

Apple  --  iPad  (Rawson,  2011) 

internet  and  technology  companies  taking  a  different 

Related 

-  Apple's  retail  stores 

-  Use  by  Children 

-  Deployed  in  Higher  Education 

approach: 

-  Introducing  a  wide  range  of  "smart"  devices, 
from  phones  to  TVs,  become  the  access 
points  to  digital  information,  which  resides 
in  the  "cloud"  (Nutall  and  Waters,  2011) 

For  aspirant  writers  the  ereader  medium  now  provides  a 
channel/outlet  for  private  label  media  publications 
(Castro,  2007)  (Egol,  2009) 

Technology 

Apple  --  Google 

Advances  in  network  medium  will  reduce  delivery  time 

Related 

--  Introduce  Operating  Systems  for  devices 
--  Google  Android  available  other  systems 

PC  makers  are  countering  the  threat  is  with  iPad- 
style  tablets  running  Android 

and  cost  and  provide  speed  of  access 

Virtualization 

-  Desktop  Virtualization  (Fogarty,  2010) 

Table  2.  Concentric  Diversification 


•  When  the  firm’s  research  and  development  organization 
produces  outstanding  diversification  by-products. 

•  When  synergy  is  not  an  important  consideration  and  therefore 
the  synergy  advantages  of  expansion  over  diversification  are 
not  important. 

Firms  may  continue  to  explore  diversification  when  the  avail¬ 
able  information  is  not  reliable  enough  to  permit  a  conclusive 
comparison  between  expansion  and  diversification. 

Ansoff  has  identified  different  forms  of  diversification— these  are 
set  out  in  Tables  1  and  2.  Table  1  depicts  Horizontal  Diversifica¬ 
tion-consisting  of  moves  within  the  economic  environment  of  the 
diversifying  firms  and  is  complementary  to  their  existing  activities, 
marketing  synergy  is  strong  as  they  continue  to  sell  through  estab¬ 
lished  marketing  channels.  This  has  been  the  lexis  for  the  changes  in 
the  supply  line,  customer  relations  and  expectation  management  in 
the  PC’s  competitive  environment;  and  Vertical  Integration— referring 
to  the  development  of  activities  which  involve  the  preceding  or  suc¬ 
ceeding  stages  in  their  production  processes  and  is  often  more  sen¬ 
sitive  to  instabilities  and  offers  less  assurance  of  flexibility— increases 
the  dependence  on  a  particular  segment  of  economic  demand— here 
most  of  the  main  competitors  are  able  to  channel  some  of  their  related 
products  and  distribution  channels  to  provide  a  competitive  edge. 

These  two  diversification  strategies  offer  limited  potential  for 
objectives;  they  make  a  limited  contribution  to  flexibility  and  stabil¬ 
ity  and  will  contribute  to  the  other  objectives  only  if  the  present 
economic  environment  of  the  firm  is  healthy  and  growing.  This 
inflection  point  is  just  as  dramatic  as  when  the  PC  came  on  the 


scene  and  cut  the  cord  between  the  mainframes  and  minis  and 
made  the  personal  computing  local.  Another  way  to  think  of  this 
is  that  we  are  moving  into  a  phase  in  which  people  want  a  PC  on 
their  desktop  and  in  their  pocket  [1 3]. 

Table  2  depicts  Concentric  Diversification— having  a  degree  of 
common  thread  with  those  firms  that  possess  marketing  and/ 
or  technology  capabilities.  A  concentric  strategy  is  generally 
flexible  and  usually  more  profitable  and  less  risky  because  of 
synergy.  For  the  PC  industry  sector  the  major  players  can  bring 
to  bear  resources  established  from  their  other  product  lines  to 
enhance  their  competitive  position. 

PCs  are  being  replaced  at  the  center  of  computing  not  by 
another  type  of  device-but  by  new  ideas  about  the  role  that  com¬ 
puting  can  play  in  progress.  According  to  Burt  [1 4],  “it  is  becoming 
clear  that  innovation  flourishes  best,  not  on  devices  but  in  the  social 
spaces  between  them,  where  people  and  ideas  meet  and  interact. 

It  is  there  that  computing  can  have  the  most  powerful  impact  on 
economy,  society  and  people’s  lives.”  Software  and  technology- 
based  companies  need  to  understand  where  computing  is  headed 
and  to  embrace  “that  which  is  technologically  inevitable”— a  future 
of  varied  devices  connected  to  the  cloud.  The  days  of  the  PC¬ 
centric  environment,  which  helped  fuel  Microsoft’s  success,  are 
declining  as  the  use  of  mobile  devices  and  cloud  computing  rises, 
implied  Ozzie,  a  Microsoft’s  chief  software  architect  [1 4]. 

At  the  unveiling  of  the  iPad  2  in  March,  2011,  then  Apple 
CEO  Steve  Jobs  affirmed  that  the  post-PC  world  would  be 
dominated  by  such  devices  as  smartphones  and  tablets.  Some 
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other  vendors  view  tablets  as  something  new  in  the  PC  market, 
but  that,  “is  not  the  right  approach  to  this,”  Jobs  said.  “These  are 
post-PC  devices  that  need  to  be  easier  to  use  than  a  PC,  more 
intuitive.  The  hardware  and  software  need  to  intertwine  more 
than  they  do  on  a  PC.” 

Given  the  diaspora  it  is  well  to  note  that  the  smartphones 
and  tablets  are  hybrids-  variations  of  not  just  the  PC  but  other 
technologies.  A  smartphone  is  a  mobile  phone  that  combines  the 
functions  of  a  personal  digital  assistant  and  a  mobile  phone- 
also  serving  as  portable  media  players  and  cameras  with  high- 
resolution  touchscreens,  web  browsers  and  mobile  broadband 
access.  A  tablet  PC  is  just  that-a  tablet-sized  computer  that 
has  the  key  features  of  a  full-size  personal  computer.  With  the 
introduction  of  the  iPad  and  later  the  Samsung  tablet,  these 
devices  have  taken  on  many  of  the  features  of  the  smartphone 
and  iPod-like  devices. 

Two  other  related  directives  altering  the  PC  are  virtualization 
and  the  cloud.  These  concepts  are  somewhat  intertwined.  Cloud 
computing  delivers  applications  via  the  Internet  and  the  web 
browser-the  business  software  and/or  user  data  are  stored  at 
remote  location.  Virtualization  is  the  creation  of  a  virtual  (rather 
than  actual)  version  of  something,  such  as  a  hardware  platform, 
operating  system,  a  storage  device  or  network  resources.  It 
can  be  viewed  as  part  of  an  overall  trend  in  enterprise  IT  that  in 
which  the  IT  environment  will  be  able  to  manage  itself  based  on 
perceived  activity,  and  utility  computing,  in  which  computer  pro¬ 
cessing  power  is  seen  as  a  utility  that  clients  can  pay  for  only  as 
needed.  These  innovations  extend  the  PC  by  enabling  any  web- 
enabled  device  to  serve  as  a  conduit  to  an  organization’s  ap¬ 
plications  and  data.  For  the  consumer  we  already  see  this  trend 
with  Google’s  Gmail  and  apps  being  stored  on  Google  servers- 
these  are  just  the  tip  of  the  data  and  application  iceberg. 

PC  sales  are  decelerating  in  the  U.S.  because  the  same 
technological  advances  that  fueled  the  PC  industry’s  rise-faster 
processors  and  lower  costs-are  now  benefiting  the  devices  that 
are  usurping  it.  Consumers  can  now  use  smaller  gadgets  to  do 
many  of  the  same  things  they  once  did  with  PCs,  such  as  surf¬ 
ing  the  Internet,  storing  photos,  and  sending  e-mail.  Apple  even 
boasts  that  users  can  edit  home  movies  on  an  iPad  [1 5]. 

In  summary,  just  as  with  the  PC  evolution  the  diaspora  is 
marked  by  several  significant  diversifications.  The  PC  itself  has 
mutated  into  many  products  ranging  from  laptops  to  mini  and 
micro  PC-laptops  to  Tablet-PCs.  Accompanying  this  mutation  is 
the  software  that  supports  this  array  of  devices-much  of  it  can 
be  found  on  other  hand-held  devices  such  as  the  BlackBerry 
and  the  smartphones.  The  promotion  and  progression  of  the 
array  of  Apple  products  ranging  from  the  iPhone  to  the  IPod  to 
the  iPad  has  created  and  fostered  not  only  a  market  niche  but 
moreover  an  extension  into  a  worldwide  set  of  devices— engen¬ 
dering  other  software  and  hardware  companies  to  follow  suit. 

The  iPad  has  come  to  be  a  multi-use  product-serving  as  an 
access  point  or  portal  to  the  web,  a  gaming  device,  a  communi¬ 
cation  medium,  and  perhaps  a  substitute  for  media  devices  such 
as  the  burgeoning  eReader  market-going  directly  against  the 
Amazon  Kindle.  The  way  that  firms  now  do  business  is  changing. 
This  also  has  fallout  to  the  consumer  that  can  now  use  a  hand¬ 
held  device  to  access  a  plethora  of  data  anywhere,  anytime,  and 
anyplace.  The  PC  is  in  some  sense  becoming  a  virtual  machine.^ 
CrossTalk-March/April  2012 
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Abstract.  A  recent  joint  technical  report  from  two  major  international  stan¬ 
dards  bodies,  the  International  Organization  for  Standardization  (ISO)  and  Inter¬ 
national  Electrotechnical  Commission  (IEC),  identifies  classes  of  vulnerabilities 
in  programming  languages-those  features  of  the  languages  that  encourage 
or  permit  the  writing  of  code  that  contains  application  vulnerabilities-and  sug¬ 
gests  ways  to  avoid  or  mitigate  them.  According  to  the  report,  programming 
language  vulnerabilities  should  especially  be  avoided  “in  the  development  of 
systems  where  assured  behavior  is  required  for  security,  safety,  mission  critical 
and  business  critical  software.  [However],  this  guidance  is  applicable  to  the 
software  developed,  reviewed,  or  maintained  for  any  application.”  This  paper 
provides  a  brief  summary  of  the  ISO/IEC  Technical  Report. 

Introduction 

The  necessity  of  mitigating  vulnerabilities  in  software  applica¬ 
tions  is  well  understood  by  organizations  today.  To  identify  them 
in  existing  applications,  organizations  can  use  vendor  alerts 
along  with  public  resources  such  as  the  Common  Vulnerabili¬ 
ties  and  Exposures  [1]  and  the  Open  Web  Application  Secu¬ 
rity  Project’s  Top  1 0  Web  Application  Security  Flaws  [2]  lists. 
Programmers  can  help  to  avoid  including  them  in  new  applica¬ 
tions  or  maintenance  of  existing  applications  by  consulting  the 
public  Common  Weakness  Enumeration  (OWE™)  [3]  and  OWE/ 
SANS  Top  25  Most  Dangerous  Software  Errors  [4]  lists.  Other 
organizations  (e.g.,  CERT  [5]  and  MISRA  [6])  have  developed 
public  or  private  style  guides  to  assist  programmers  in  avoiding 
application  vulnerabilities. 

An  application  vulnerability  is  a  weakness  in  a  software  ap¬ 
plication  that  permits  exploitation  by  unauthorized  persons  or 
contributes  to  safety  hazards.  The  frequent  patches  provided  by 
our  software  vendors  have  alerted  most  of  us  to  the  problem  of 
vulnerabilities  in  software  designs.  Not  as  well  known,  however, 
is  that  the  programming  languages  in  which  software  applica¬ 
tions  are  written,  also  have  vulnerabilities  of  their  own  that  can 
cause  applications  not  to  work  as  intended,  behave  in  unpredict¬ 
able  ways,  or  lead  to  application  vulnerabilities.  Simply  stated, 


deficiencies  in  the  design  of  programming  languages  encourage 
programmers  to  code  in  a  manner  that  creates  application  vul¬ 
nerabilities.  The  consequences  for  organizations  can  be  costly 
as  well  as  dangerous. 

To  address  this  problem,  ISO  [7]  and  IEC  [8]  issued  a  Techni¬ 
cal  Report  entitled  ISO/IEC  TR  24772:2010,  Information 
technology-Programming  languages-Guidance  to  avoiding 
vulnerabilities  in  programming  languages  through  language 
selection  and  use  [9],  in  September  2010  that  lists  51  common 
types  of  vulnerabilities  found  in  programming  languages,  along 
with  suggestions  for  how  to  avoid  them.  The  report  also  lists  20 
application  vulnerabilities  that  could  be  addressed  by  improved 
language  library  routines. 

No  one  language  contains  all  of  the  vulnerabilities  described 
in  the  report,  but  most  are  very  common.  In  addition,  1  7  of  the 
vulnerabilities  detailed  in  the  report  also  appear  on  the  2010 
CWE/SANS  Top  25  Most  Dangerous  Software  Errors  list. 

Reduce  Risk  by  Mitigating  Programming 
Language  Vulnerabilities 

By  understanding  the  different  ways  in  which  their  program¬ 
ming  languages  might  be  vulnerable,  writers  of  language 
standards  can  eliminate  or  reduce  those  vulnerabilities  in  their 
languages  and  thereby  make  them  more  secure.  In  turn,  ap¬ 
plication  developers  can  know  how  secure  a  language  is  before 
choosing  it.  Developers  will  also  be  able  to  ensure  that  the 
potential  for  vulnerabilities  in  their  applications  are  minimized 
in  their  software  applications,  and  that  they  have  chosen  the 
most  effective  and  comprehensive  source  code  evaluation  tools. 
Project  managers  can  use  the  guide  to  make  better-informed 
selections  of  programming  languages  and  establish  mitigations 
for  the  risks  inherent  in  the  chosen  language. 

This  is  of  special  importance  to  those  who  develop,  maintain, 
and  regulate: 

•  Safety-critical  applications  that  might  cause  loss  of  life, 
human  injury,  or  damage  to  the  environment. 

•  Security-critical  applications  that  must  ensure  properties  of 
confidentiality,  integrity,  and  availability. 

•  Mission-critical  applications  that  must  avoid  loss  or  damage  to 
property  or  finance. 

•  Business-critical  applications  where  correct  operation  is 
essential  to  the  successful  operation  of  the  business. 

•  Scientific,  modeling,  and  simulation  applications  that  require 
high  confidence  in  the  results  of  possibly  complex,  expensive, 
and  extended  calculation. 

Reducing  risk  in  all  of  these  areas  will,  over  time,  yield  organiza¬ 
tions  cost  savings  due  to  less  work,  and  ultimately  lead  to  more 
secure  systems. 

Types  of  Programming  Language  Vulnerabilities 

When  a  programmer  writes  a  software  application,  regard¬ 
less  of  the  programming  language  used-be  it  Ada,  C,  COBOL, 
Fortran,  etc. -the  code  should  execute  in  a  manner  that  can  be 
predicted  by  the  developer.  If  it  does  not,  and  an  attacker  can 
then  make  use  of  the  mistake  to  access  a  system  or  network,  it 
is  considered  a  vulnerability  in  the  software  code. 
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With  programming  languages,  vulnerabilities  arise  in  six 
main  ways: 

Incomplete  or  Evolving  Programming 
Language  Behavior 

Programming  language  standards  are  continuously  evolv¬ 
ing  with  new  releases  and  features,  resulting  in  issues  that 
might  affect  predictability.  Such  issues  include  the  need  for 
compatibility  with  previous  releases,  and  the  interaction  of  that 
language’s  features,  separately  and  in  any  combination,  under 
all  foreseeable  circumstances. 

Choice  of  compiler  can  also  have  an  effect.  Compilers  are 
used  by  programmers  to  transform  their  source  code  to  a  binary 
code  (commonly  called  object  code).  However,  unless  the  com¬ 
piler  comes  from  a  trusted  source  and  was  developed  according 
to  agreed  standards,  it  could  inadvertently  or  maliciously  insert 
bad  code  into  the  binary,  resulting  in  a  potential  vulnerability. 

This  is  especially  important  to  avoid  because  this  type  of  vulner¬ 
ability  would  then  be  inserted  into  every  piece  of  software  that 
the  compiler  processes. 

Unspecified  behavior  must  also  be  avoided.  While  most 
behavior  is  specified  by  programming  languages,  unspecified 
behaviors  can  result  when  a  programming  language  construct  is 
specified  to  have  two  or  more  possibilities  of  behavior.  In  such  a 
case,  different  compilers  may  generate  different  behaviors  from 
the  same  source  code,  resulting  in  a  vulnerability.  The  problem 
is  exacerbated  if  the  compiler(s)  are  run  on  different  computers; 
if  the  compilers  use  different  software  libraries;  or  if  they  run  on 
different  operating  systems,  different  releases  of  an  operating 
system,  or  different  configurations  of  an  operating  system. 

Another  issue  is  implementation-defined  behavior.  Program¬ 
ming  languages  sometimes  allow  compilers  to  support  a  variety 
of  behaviors  for  a  single  language  feature,  or  combination  of 
features,  that  may  enable  usage  on  a  wider  range  of  hardware 
or  enable  use  of  the  language  in  a  wider  variety  of  circumstanc¬ 
es.  However,  there  is  a  requirement  that  each  implementation 
document  the  behavior.  Vulnerabilities  can  occur  when  the  pro¬ 
grammer  does  not  take  into  account  this  documented  behavior 
or  ports  code  from  one  machine  to  another  without  considering 
changes  in  implementation-defined  behavior. 

Undefined  behavior  is  also  a  threat.  Programming  languages 
sometimes  specify  that  program  behavior  is  undefined  or  simply 
leave  some  behavior  undefined.  Common  examples  include  recovery 
from  an  error  in  the  software,  and  use  of  the  value  of  a  variable  that 
has  not  yet  been  assigned.  In  some  cases,  attackers  can  use  expert 
knowledge  to  stimulate  behavior  that  can  lead  to  a  vulnerability. 

Human  Cognitive  Limitations 

Programming  languages  are  created  with  different  purposes, 
some  are  for  general  use  and  others  for  specific  tasks  or  needs, 
but  all  are  created  as  tools  to  be  used  by  software  programmers 
to  manipulate  data  and  produce  a  desired  result.  This  means 
the  intended  audiences  for  the  languages  are  different.  For 
instance,  C  was  created  for  programmers  implementing  system 
software,  while  COBOL  was  created  for  programmers  writing 
business  applications. 

Because  everyone  is  different  and  each  person  has  their  own 
levels  of  understanding  and  areas  of  expertise,  vulnerabilities 
can  occur  because  of  the  abilities  of  the  person  writing  the  code 
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as  well  as  by  those  who  maintain  it.  Programmers  may  choose 
syntaxes  that  make  the  most  sense  to  them,  even  though  the 
language  provides  another  syntax  that  would  accomplish  the 
same  task,  or  may  have  performed  the  function  more  efficiently. 
Also,  as  people,  programmers  have  to  deal  with  the  stresses  of 
their  personal  and  professional  lives,  any  of  which  may  have  an 
impact  on  the  quality  of  code  that  person  writes,  which  could  in 
turn  result  in  a  potential  vulnerability. 

This  can  be  addressed  by  standardizing  and  simplifying  as 
much  as  possible,  and  by  improving  documentation  and  resourc¬ 
es,  including  project  coding  standards  and  review  processes, 
that  directly  deal  with  these  issues. 

Lack  of  Portability  and  Interoperability 

In  addition  to  potential  issues  resulting  from  how  code  is 
written  and  from  variations  in  the  compilers  or  configurations  of 
the  same  compiler,  other  factors  can  result  in  potential  vulner¬ 
abilities  when  the  application  is  run,  such  as  if  the  application 
is  used  with  different  software  libraries,  on  different  operating 
systems,  or  on  different  hardware. 

Developers  must  be  aware  of  these  possibilities  and  plan  for 
them,  for  instance,  by  using  only  semantics  specifically  defined 
by  the  language,  and  by  using  software  libraries  specifically  cre¬ 
ated  for  the  language  whenever  possible. 

Inadequate  Intrinsic  Support  in  the  Language 

Although  using  specified  software  libraries  for  an  application 
can  reduce  risk,  sometimes  no  libraries  are  specified  by  the  pro¬ 
gramming  language  or  the  libraries  used  are  not  validated  to  the 
same  standard  as  the  compiler  and  the  applications  being  devel¬ 
oped,  are  proprietary  and  inclined  to  change  in  later  releases,  or 
are  discontinued  and  no  longer  supported  by  the  vendor.  Such 
instances  can  lead  to  potential  vulnerabilities. 

A  programmer  can  reduce  this  risk  by  using  stronger  types  or 
controls  to  perform  certain  operations,  though  this  may  reduce 
the  performance  and  flexibility  of  the  application.  Therefore,  the 
developer  must  strike  a  balance  between  the  intrinsic  support 
provided  by  the  language  to  help  avoid  vulnerabilities  and  the 
ultimate  utility  of  the  application. 

Language  Features  Prone  to  Erroneous  Use 

In  some  programming  languages  the  syntactic  constructs 
used  by  the  language  are  simple  and  straightforward  to  use, 
while  others  in  that  same  language  are  extremely  complex. 
Vulnerabilities  can  result  when  language  constructs  are  used 
improperly,  when  complex  constructs  are  misused  in  acceptable 
but  unintended  ways,  or  when  complex  constructs  that  can  be 
substituted  for  by  a  series  of  simpler  constructs  are  used  with¬ 
out  an  understanding  of  the  full  effects  of  the  constructs. 

Such  vulnerabilities  can  be  reduced  by  those  creating  the 
language  by  identifying  such  constructs,  and  providing  standard¬ 
ized  ways  for  dealing  with  them. 

The  common  strand  throughout  all  of  the  causes  listed 
above  is  lack  of  knowledge.  With  perfect  knowledge,  the  ex¬ 
ecution  of  code  can  be  predicted,  but  this  is  seldom  the  case. 
Expert  attackers  can  exploit  superior  knowledge  to  “trick”  the 
code  into  executing  function  that  the  code’s  developer  did  not 
intend  or  foresee. 
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Example  Vulnerabilities 

An  example  of  a  vulnerability  described  in  the  Technical  Re¬ 
port  would  be  the  following: 

When  subexpressions  with  side  effects  are  used  within  an 
expression,  the  unspecified  order  of  evaluation  can  result  in 
a  program  producing  different  results  on  different  platforms, 
or  even  at  different  times  on  the  same  platform.  For  example, 
consider 

a  =  f(b)  +  g(b); 

where  f  and  g  both  modify  b.  If  f(b)  is  evaluated  first,  then  the 
b  used  as  a  parameter  to  g(b)  may  be  a  different  value  than  if 
g(b)  is  performed  first.  Likewise,  if  g(b)  is  performed  first,  f(b) 
may  be  called  with  a  different  value  of  b. 

Other  examples  of  unspecified  order,  or  even  undefined 
behavior,  can  be  manifested,  such  as 

a  =  f(i)  +  i++; 

or 

a[i++]  =  b[i++]; 

Parentheses  around  expressions  can  assist  in  removing 
ambiguity  about  grouping,  but  the  issues  regarding  side  effects 
and  order  of  evaluation  are  not  changed  by  the  presence  of 
parentheses;  consider 

j  =  i++  *  i++; 

where  even  if  parentheses  are  placed  around  the  i++  subex¬ 
pressions,  undefined  behavior  still  remains.  (This  example  uses 
the  syntax  of  C;  the  effects  can  be  created  in  any  language 
that  allows  functions  with  side  effects  in  the  places  where  the 
example  shows  the  increment  operations.) 

In  this  case,  the  report  suggests  that  programmers  should 
decompose  the  expression  into  sequential  statements  so  that 
the  order  of  evaluation  can  be  controlled. 

The  unpredictable  nature  of  the  calculation  means  that  the 
program  cannot  be  tested  adequately  to  any  degree  of  confi¬ 
dence.  A  knowledgeable  attacker  can  take  advantage  of  this 
characteristic  to  manipulate  data  values  triggering  execution 
that  was  not  anticipated  by  the  developer. 

An  example  of  an  application  vulnerability  included  in  the 
report  would  be  storing  a  password  in  vulnerable  cleartext  be¬ 
cause  the  programming  language  did  not  provide  a  library  func¬ 
tion  for  encrypting  the  password.  For  this  problem,  the  project 
should  acquire  a  subroutine  library  that  provides  the  functionality 
missing  from  the  language  library. 

A  Catalog  of  Language  Vulnerability  Types 

Vulnerabilities  included  in  the  report  were  identified  and 
selected  using  two  different  analyses.  A  bottom-up  analysis 
surveyed  application  security  vulnerabilities  observed  “in  the 
wild”  and  identified  language  characteristics  that  can  serve  as 
root  causes  of  the  application  vulnerabilities.  A  top-down  analy¬ 
sis  surveyed  existing  language  style  and  usage  guides  for  the 
production  of  safety-related  software. 


All  language  vulnerabilities  in  the  ISO/I  EC  report  are  de¬ 
scribed  in  a  language-independent  manner  allowing  readers  to 
quickly  comprehend  and  utilize  the  information. 

Programming  Language  Vulnerability  Description 

Each  type  of  programming  language  vulnerability  is  described 
in  a  uniform  format  to  permit  easy  reference.  Information  in  the 
description  includes: 

•  An  arbitrary  three-letter  identifier  that  can  be  used  to  identify 
the  vulnerability. 

•  A  brief  summary  of  the  programming  language  vulnerability. 

•  Cross-references,  such  as  CWE  identifier. 

•  A  description  of  the  mechanism  of  failure,  giving  the  link 
between  the  programming  language  vulnerability  and  resulting 
application  vulnerabilities. 

•  A  list  summarizing  the  characteristics  of  languages  for  which 
this  vulnerability  is  applicable. 

•  A  brief  description  of  how  application  developers  can  avoid 
the  vulnerability  or  mitigate  its  negative  effects. 

•  Comments  regarding  how  the  maintainers  of  the  language’s 
specification  might  make  improvements. 

Application  Vulnerability  Description 

The  report  also  lists  a  handful  of  application  vulnerabilities 
that  might  be  mitigated  if  better  support  were  provided  in 
programming  language  libraries.  These  are  described  similarly 
to  the  language  vulnerabilities,  except  that  the  comments  to 
language  maintainers  are  omitted. 

An  Ongoing  Process 

The  list  of  vulnerabilities  detailed  in  the  ISO/I  EC  report  is  not 
complete.  With  new  vulnerabilities  being  discovered  regularly, 
the  process  will  always  be  ongoing.  The  report  therefore  only 
describes  those  programming  language  vulnerability  types  that 
were  determined  to  have  sufficient  probability  and  significance 
to  date. 

In  addition,  the  following  five  subject  areas  were  not  ad¬ 
dressed  in  this  initial  release  but  will  be  addressed  in  future 
editions  of  the  report: 

•  Object-oriented  language  features,  though  certain  simple 
issues  related  to  inheritance  are  discussed. 

•  Concurrency. 

•  Numerical  analysis,  though  certain  simple  items  regarding  the 
use  of  floating  point  are  discussed. 

•  Scripting  languages. 

•  Inter-language  operability. 

The  second  edition  of  the  Technical  Report  will  also  add 
annexes  describing  how  the  vulnerabilities  appear  in  particular 
programming  languages.  Currently,  annexes  are  planned  for 
Ada,  C,  Python,  Ruby  and  SPARK.  Future  editions  will  add  more 
language-specific  annexes  as  well  as  describing  additional 
vulnerabilities. 

The  report  is  available  for  purchase  from  <http://www.iso. 
org>  and  <http://www.ansi.org>.  Individual  users  can  obtain  the 
report  for  free  at  <http://standards.iso.org/ittf/PubliclyAvail- 
ableStandards/index.html>. 
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About  ISO/IEC  Standards 
and  Technical  Reports 

There  are  three  major  international  standards  associations 
that  bring  together  national  bodies  from  participating  nations, 
as  well  other  international  governmental  and  nongovernmental 
organizations,  to  focus  on  the  development  of  international 
standards  for  business,  government,  and  society— the  ISO,  I  EC, 
and  International  Telecommunication  Union  [10]. 

While  the  primary  work  of  ISO  and  I  EC  is  to  prepare  interna¬ 
tional  standards,  some  subjects  are  not  appropriate  for  stan¬ 
dardization  but  are  suitable  for  technical  reports  that  provide 
guidance  and  information  that  have  been  formed  via  consensus. 

The  ISO/IEC  report  about  programming  language  vulnerabil¬ 
ity  types  discussed  in  this  article,  Technical  Report  24772:201 0, 
was  published  by  a  subcommittee  working  group  of  the  ISO/ 

I  EC  Joint  Technical  Committee  for  the  field  of  information  tech¬ 
nology  that  is  responsible  for,  “programming  languages,  their 
environments,  and  system  software  interfaces.” 
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Abstract.  This  paper  describes  the  scope  of  the  problem  regarding  software 
vulnerabilities  and  the  current  state  of  the  practice  in  static  code  analysis  for 
software  assurance.  Recommendations  are  made  regarding  the  use  of  static 
analysis  methods  and  tools  during  the  software  life.  Static  code  analysis  touch 
points  during  lifecycle  reviews  and  challenges  to  automated  static  code  analy¬ 
sis  are  also  discussed. 

Section  1.  Introduction 
Managing  software  risk  in  the  supply  chain  is  in  large  part 
about  discovering  and  understanding  the  vulnerabilities  that 
might  exist  in  code  that  you  might  buy  as  standalone  applica¬ 
tions  or  integrate  into  other  systems  or  products.  It  is  also 
about  vulnerabilities  you  might  build  into  code  that  you  develop 
in-house.  Static  code  analysis  can  be  an  effective  means  for 
determining  the  vulnerabilities  in  your  code. 


SECURING  A  MOBILE  WORLD 

a.  Scope  of  the  Problem 

Capers  Jones  [1  ]  described  the  results  of  a  survey  of  the 
U.S.  software  industry  as  of  2008.  Based  on  those  data,  Tables 
1  and  2  address  the  number  and  severity  of  software  vulner¬ 
abilities  in  several  classes  of  application  projects.  For  military 
projects,  as  one  approaches  systems  the  size  of  typical  large 
combat  systems  (expressed  as  function  points),  the  estimated 
number  of  security  vulnerabilities  rises  to  above  3000  and  the 
probability  of  serious  vulnerabilities  rises  to  45%.  The  statistics 
are  much  worse  for  civilian  and  commercial  systems.  These 
systems  have  tended  to  make  much  more  extensive  use  of 
COTS.  As  we  move  more  and  more  into  COTS  and  open  source 
software  for  our  national  defense  and  critical  infrastructure  sys¬ 
tems,  one  might  expect  that  the  extent  of  vulnerabilities  in  these 
critical  systems  might  nearly  double. 

In  a  study  by  Reifer  and  Bryant  [2],  1 00  packages  were 
selected  at  random  from  50  public  open  source  and  COTS  li¬ 
braries.  These  spanned  a  full  range  of  applications  and  sites  like 
SourceForge.  The  packages  were  analyzed  by  college  students 
using  a  variety  of  tools. 


Commercial 

Projects 

Civilian 

Government 

Projects 

Military 

Projects 

Average 

Size  in  FP 

1 

1 

1 

1 

1 

10 

5 

5 

4 

5 

100 

28 

29 

14 

24 

1,000 

150 

155 

55 

120 

10,000 

794 

832 

209 

600 

100,000 

4,217 

4,467 

794 

3,031 

1,000,000 

22,387 

23,988 

3,020 

15,412 

Average 

3,940 

4,211 

585 

2,742 

Table  1.  Estimated  Number  of  Vulnerabilities  in  Software  Applications 


Commercial 

Projects 

Civilian 

Government 

Projects 

Military 

Projects 

Average 

Size  in  FP 

1 

15.00% 

25.00% 

5.00% 

11.29% 

10 

30.00% 

35.00% 

15.00% 

26.00% 

100 

40.00% 

45.00% 

20.00% 

33.57% 

1,000 

60.00% 

62.00% 

30.00% 

54.57% 

10,000 

77.00% 

80.00% 

35.00% 

74.00% 

100,000 

85.00% 

87.00% 

40.00% 

80.14% 

1,000,000 

96.00% 

92.00% 

45.00% 

86.29% 

Average 

57.57 % 

60.86% 

27.14% 

52.27% 

Table  2.  Probability  of  Serious  Security  Vulnerabilities  in  Software  Applications 


The  objectives  were  to: 

•  Determine  if  the  packages  were  up-to-date  with  respect  to 
vendor  identified  vulnerabilities  and  patches 

•  Assess  if  packages  were  free  of  known  viruses,  worms, 
Trojans  and  spyware 

•  Assess  if  the  packages  had  weaknesses  in  the  code  and 
backdoors,  using  reverse  engineering  techniques 

•  Assess  if  the  packages  had  potential  dead  code,  malware, 
unwanted  behaviors,  or  undesired  functionality 
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Figure  1.  COTS  Study  Findings.  Source:  D.  Reifer  and  E.  Bryant,  Software 
Assurance  in  COTS  and  open  source  Packages,  DFIS  Software  Assurance 
Forum,  October  2008 


Figure  1  describes  the  results  of  this  small  study.  Over  30% 
of  open  source  and  Government  Off  the  Shelf  (GOTS)  packages 
analyzed  had  dead  code,  an  anathema  to  the  software  safety 
community,  and  a  concern  of  the  software  security  community 
as  well.  Over  20%  of  the  open  source,  COTS,  and  GOTS  pack¬ 
ages  had  suspected  malware,  and  over  30%  of  the  COTS 
packages  analyzed  had  behavioral  problems. 

Reifer  and  Bryant  conclude  that  the  potential  for  malicious 
code  in  applications  software  is  large  as  more  and  more  pack¬ 
ages  are  used  in  developing  a  system.  They  have  been  devel¬ 
oping  a  tool  for  analyzing  software  executables,  often  the  only 
thing  available  from  COTS  suppliers.  They  have  a  method  and 
tool  that  is  available  now.  These  focus  on  analyzing  software 
executables,  often  the  only  thing  available  from  COTS  suppliers. 

b.  What  is  Static  Source  Code  Analysis? 

Static  analysis  is  the  process  of  evaluating  a  system  or 
component  based  on  its  form,  structure,  content,  or  docu¬ 
mentation  [3].  From  a  software  assurance  perspective,  static 
analysis  addresses  weaknesses  in  program  code  that  might 
lead  to  vulnerabilities.  Such  analysis  may  be  manual,  as  in  code 
inspections,  or  automated  through  the  use  of  one  or  more 
tools.  A  static  analysis  tool  is  a  program  written  to  analyze  other 
programs  for  flaws  [4].  Such  analyzers  typically  check  source 
code.  There  is  also  a  smaller  set  of  analyzers  that  check  byte 
code  and  binary  code  as  well.  While  testing  requires  code  that  is 
relatively  complete,  static  analysis  can  be  performed  on  modules 
or  unfinished  code.  Manual  analysis,  or  code  inspection,  can  be 
very  time-consuming,  and  inspection  teams  must  know  what 
security  vulnerabilities  look  like  in  order  to  effectively  examine 
the  code.  Static  analysis  tools  are  faster  and  do  not  require  the 
tool  operator  to  have  the  same  level  of  security  expertise  as  a 
code  inspector  [5]. 


Section  2.  Strategies  for  Effective  Source 
Code  Analysis 

a.  What  Code  Do  You  Analyze? 

How  do  you  prioritize  a  code  review  effort  when  you  have 
thousands  of  lines  of  source  code,  and  perhaps  object  code 
to  review?  From  a  software  assurance  perspective,  looking  at 
attack  surfaces  is  not  a  bad  place  to  start  [6].  A  system’s  at¬ 
tack  surface  can  be  thought  of  as  the  set  of  ways  in  which  an 
adversary  can  enter  the  system  and  potentially  cause  damage. 
The  larger  the  attack  surface,  the  more  insecure  the  system 
[7].  Higher  attack  surface  software  requires  deeper  review  than 
code  in  lower  attack  surface  components.  Howard  [8]  proposes 
several  heuristics  as  an  aid  to  determining  code  review  priority, 
that  is,  given  a  large  amount  of  code  to  review,  what  kinds  of 
code  do  you  emphasize  for  review.  They  are  summarized  below: 

Legacy  code:  Howard  points  out  that  legacy  code  may  have 
more  vulnerabilities  than  newly  developed  code  because  secu¬ 
rity  issues  likely  were  not  as  well  understood  when  the  legacy 
code  was  created. 

Code  that  runs  by  default:  Howard  suggests  that  attackers 
will  often  attempt  to  exploit  code  that  runs  by  default.  He  also 
suggests  that  code  running  by  default  increases  an  applica¬ 
tion’s  attack  surface,  which  is  a  product  of  all  code  accessible 
to  attackers. 

Code  that  runs  in  elevated  context:  Code  that  runs  with  el¬ 
evated  privileges,  e.g.  root  privileges,  for  example,  should  also  be 
reviewed  earlier  and  deeper  because  compromise  of  such  code 
can  allow  attackers  to  execute  commands  that  are  intended  only 
for  privileged  users  such  as  a  site  administrator. 

Anonymously  accessible  code:  Howard  suggests  that 
code  that  permits  anonymous  access  should  be  reviewed  in 
greater  depth  than  code  that  only  allows  access  to  valid  users 
and  administrators. 

Code  connected  to  a  globally  accessible  network  interface: 

Howard  strongly  states  that  code  that  interfaces  with  a  network, 
especially  uncontrolled  networks  like  the  Internet,  presents  sub¬ 
stantial  risk.  Such  code  increases  the  potential  attack  surface  for 
the  system. 

Code  written  in  a  language  whose  features  facilitate 
building  in  vulnerabilities:  Howard  suggest  that  code  writ¬ 
ten  in  languages  like  C  and  C++,  have  features,  like  direct 
memory  access,  that  allow  programmers  to  inadvertently  insert 
vulnerabilities,  like  buffer-overflow  vulnerabilities.  Howard  also 
points  out  other  language  vulnerabilities,  such  as  SQL-injection 
vulnerabilities  in  Java,  or  C#  code.  ISO/IEC  TR  24772:2010 
[9]  specifies  software  programming  language  vulnerabilities  to 
be  avoided  where  assured  behavior  is  required.  These  vulner¬ 
abilities  are  described  in  a  generic  manner  that  is  applicable  to  a 
broad  range  of  programming  languages. 

Code  with  a  history  of  vulnerabilities:  Code  that  has  had 
a  number  of  past  security  vulnerabilities  should  be  suspect, 
unless  it  can  be  demonstrated  that  those  vulnerabilities  have 
been  effectively  removed. 
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Code  that  handles  sensitive  data:  Code  that  handles  sensi¬ 
tive  data  should  be  analyzed  to  ensure  that  weaknesses  in  the 
code  not  compromise  such  data  by  disclosing  it  to  untrusted  users. 

Complex  code:  Complex  code  has  a  higher  bug  probability, 
is  more  difficult  to  understand,  and  may  likely  have  more  secu¬ 
rity  vulnerabilities. 

Code  that  changes  frequently:  Howard  points  out  that 
frequently  changing  code  often  results  in  new  bugs  being 
introduced.  Not  all  of  these  bugs  will  be  security  vulnerabilities, 
but  compared  with  a  stable  set  of  code  that  is  updated  only 
infrequently,  code  that  is  less  stable  will  probably  have  more 
vulnerabilities  in  it. 

b.  A  Three-phase  Code  Analysis  Process 

Howard  [8]  also  suggests  a  notional  three-phase  code  analy¬ 
sis  process  that  optimizes  the  use  of  static  analysis  tools. 

1.  Phase  1  -  Run  all  available  code-analysis  tools 
Howard  suggests  that  multiple  tools  should  be  used  to  offset 

tool  biases  and  minimize  false  positives  and  false  negatives.  This 
makes  great  sense  if  your  organization  can  afford  it.  Strengths 
and  weaknesses  vary  from  tool  to  tool  [10,  11  ].  Warnings  from 
multiple  tools  may  indicate  code  that  needs  closer  scrutiny 
through  manual  inspection. 

Additionally,  these  tools  are  most  effective  when  run  early  in 
the  lifecycle  and  run  often  [1 2] 

Howard  also  suggests  that  code  should  be  evaluated  early, 
and  re-evaluated  throughout  its  development  cycle. 

2.  Phase  2  -  Look  for  common  vulnerability  patterns 
Howard  recommends  that  analysts  make  sure  that  code 

reviews  cover  the  most  common  vulnerabilities  and  weaknesses. 
Sources  for  such  common  vulnerabilities  and  weaknesses 
include  the  Common  Vulnerabilities  and  Exposures  (CVE)  and 
Common  Weaknesses  Enumeration  (CWE)  databases,  main¬ 
tained  by  the  MITRE  Corporation  and  accessible  on  the  web 
at:  <http://cve.mitre.org/cve/>  and  <http://cwe.mitre.org/>. 
MITRE,  in  cooperation  with  the  SANS  Institute,  also  maintains 
a  list  of  the  “Top  25  Most  Dangerous  Programming  Errors  [13]” 
that  can  lead  to  serious  vulnerabilities.  The  top  three  classes 
of  errors  as  of  December  2010  were  cross-site  scripting,  SQL 
injection,  and  buffer  overflows.  Static  code  analysis  tool  and 
manual  techniques  should  at  a  minimum,  address  these  Top  25. 

3.  Phase  3  -  Use  manual  analysis  for  risky  code 
Howard  also  suggests  that  analysts  should  also  use  manual 

analysis  (e.g.  code  inspection)  to  more  thoroughly  evaluate  any 
risky  code  that  has  been  identified  based  on  the  attack  surface, 
or  based  on  the  heuristics  described  earlier.  Manual  analysis 
allows  detailed  tracing  of  code  paths  and  data  usage. 

Section  3.  The  Assurance  Case 

An  Assurance  Case  is  a  set  of  structured  assurance  claims, 
supported  by  evidence  and  reasoning  that  demonstrates  how 
assurance  needs  have  been  satisfied  [14]. 

•  It  shows  compliance  with  assurance  objectives. 

•  It  provides  an  argument  for  the  safety  and  security  of  the 
product  or  service. 

•  It  is  built,  collected,  and  maintained  throughout  the  lifecycle. 

•  It  is  derived  from  multiple  sources. 


Systeny  Software,  or  Service 


Makes  the  case  for  adequate  assurance  of  the 


Figure  2.  The  Assurance  Case 


As  shown  in  Figure  2,  the  Assurance  Case  should  be  used 
to  document  claims  about  the  security  of  a  software  product  or 
system.  Those  claims  must  be  supported  by  arguments  regard¬ 
ing  the  security  characteristics  of  the  software,  and  those  argu¬ 
ments  must  be  firmly  supported  by  evidence. 

The  results  obtained  from  static  code  analysis  provide  evi¬ 
dence  regarding  vulnerabilities  in  code,  and  should  be  docu¬ 
mented  as  part  of  the  Assurance  Case. 

The  Sub-parts  of  an  assurance  case  include: 

•  A  high  level  summary 

•  Justification  that  product  or  service  is  acceptably  safe, 
secure,  or  dependable 

•  Rationale  for  claiming  a  specified  level  of  safety  and  security 

•  Conformance  with  relevant  standards  and  regulatory 
requirements 

•  The  configuration  baseline 

•  Identified  hazards  and  threats  and  residual  risk  of  each  hazard 
and  threat 

•  Operational  and  support  assumptions 

An  Assurance  Case  should  be  part  of  every  acquisition  in 
which  there  is  concern  for  IT  security.  It  should  be  prepared 
by  the  supplier  and  describe  the  assurance-related  claims  for 
the  software  being  delivered,  the  arguments  backing  up  those 
claims,  and  the  hard  evidence  supporting  those  arguments. 

The  details  of  how  static  code  analysis  was  used  in  the  devel¬ 
opment  process  and  the  results  of  such  static  analysis  should 
be  included  to  support  assurance  arguments. 

Section  4.  Static  Code  Analysis  in  the  Software  Lifecycle 

Project  Managers  (PMs)  have  a  responsibility  to  ensure  that 
security  requirements  are  addressed  throughout  the  software 
lifecycle.  This  responsibility  includes  conducting  risk  assess¬ 
ments;  documenting  system  threats  and  vulnerabilities,  including 
test  and  remediation  plans  on  a  continuing  basis.  Static  code 
analysis  contributes  to  documenting  system  weaknesses 
and  vulnerabilities. 
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Figure  3.  Reviews  in  the  Software  Lifecycle 


Static  code  analysis  should  be  applied  at  several  points  in  the 
software  acquisition  and  development  lifecycle. 

The  reviews  that  are  associated  with  software  are  shown  in 
Figure  3  [1 5].  The  following  discussion  addresses  the  objectives 
and  expected  outcomes  of  these  reviews,  describing  the  touch 
points  for  static  code  analysis  in  the  software  lifecycle  review 
process  [1 6]. 

a.  System  Requirements  Review  (SRR) 

1 .  Objectives 

The  SRR  helps  the  PM  understand  the  scope  of  the  software 
assurance  landscape  (assurance  requirements,  elements  to  be 
protected,  the  threat  environment)  in  which  context  static  code 
analysis  should  be  applied. 

2.  Outcomes 

•  Establishment  of  the  System  Assurance  Case 

The  Assurance  Case  both  sets  the  context  for  static  code 
analysis  and  provides  a  repository  for  analysis  results.  As 
discussed  earlier  and  emphasized  here,  the  Assurance  Case 
should  include: 

-Specification  of  the  top-level  system  assurance  claims  that 
address  identified  threats. 

-Identification  of  the  approach  for  developing  the  system  as¬ 
surance  case. 

-Identification  of  all  critical  elements  to  be  protected. 

-Identification  of  all  relevant  system  assurance  threats  and 
their  potential  impact  on  critical  system  assets. 

-Identification  of  high-level  potential  weaknesses  in  the  system. 

-Determination  and  derivation  of  system  assurance  require¬ 
ments  (as  a  subset  of  the  system  requirements). 

•  Test  and  Evaluation  Master  Plan  (TEMP)  addressing 
system  assurance. 

The  TEMP  or  establishes  the  test  strategy  for  testing 
throughout  the  development  lifecycle. 

-Examine  the  TEMP  to  ensure  testing  processes  are  suf¬ 
ficient  for  system  assurance.  This  may  include  planning  for  static 
code  analysis. 

•  Support  and  Maintenance  Concepts 

Support  and  Maintenance  concepts  addresses  the  need  to 
address  assurance  concerns  beyond  development,  throughout 
the  life  of  the  system.  Outcomes  include: 

-Documentation  of  the  support  and  maintenance  concepts 
including  a  description  of  how  assurance  will  be  maintained. 
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-Description  of  what  static  code  analysis  tools  will  be  used 
post  deployment  and  how  and  when  they  will  be  applied. 

b.  Preliminary  Design  Review  (PDR) 

1 .  Objectives 

The  PDR  is  a  multi-disciplined  technical  review  to  ensure  that 
the  system  under  review  can  proceed  into  detailed  design,  and 
can  meet  the  stated  performance  requirements  within  cost  (pro¬ 
gram  budget),  schedule  (program  schedule),  risk,  and  specific 
assurance  requirements  and  constraints. 

2.  Outcomes 

•  Information  security  technology  evaluation  of  all  critical 
COTS/GOTS  elements. 

As  discussed  earlier,  COTS/GOTS  components  might  present 
security  risks.  As  part  of  the  analysis  of  alternatives  process, 
candidate  components  should  be  vetted  with  respect  to  their 
security  characteristics.  The  Assurance  Case  should  also  be 
updated  based  on  the  components  selected,  and  any  new 
weaknesses  and  vulnerabilities  identified. 

The  outcomes  from  the  evaluation  of  COTS/GOTS  elements 
should  include: 

-Specification  of  assurance-specific  static  analysis  and 
assurance-specific  criteria  to  be  examined  during  code  reviews. 

-Documentation  of  the  results  of  static  code  analyses  per¬ 
formed  on  GOTS/COTS  components. 

-Documentation  regarding  which  tools  were  used  to  perform 
static  code  analysis. 

-Documentation  of  weaknesses  and  vulnerabilities  that 
were  discovered. 

-Documentation  of  code  reviews  performed  during  implementation. 

•  Configuration  management. 

The  preliminary  configuration  management  plan  must  support 
protection  of  each  configuration  item,  addressing  vulnerabilities 
that  might  creep  in  during  the  change  process.  This  includes 
requirements,  architectures,  designs,  and  code.  The  outcomes 
associated  with  configuration  management  include: 

-Discussion  regarding  at  which  stages  of  the  configuration 
management  process  static  code  analysis  will  be  applied. 

-Discussion  of  what  configuration  change  events  will  trigger 
code  analysis. 

-Description  of  which  components  will  be  analyzed. 

-Description  of  how  the  results  of  the  analyses  will  be  docu¬ 
mented. 

The  Assurance  Case  should  also  be  updated  with  relevant 
evidence  as  a  result  of  the  PDR. 

3.  Other  Considerations 

Use  of  COTS  and  open  source  presents  a  supply  chain  as¬ 
surance  challenge.  As  part  of  an  analysis  of  the  supplier  and  its 
processes,  the  following  should  be  determined. 

•  Will  the  supplier  perform  static  code  analysis  as  part  of  its 
code  development  and/or  code  integration  processes? 

•  Which  components  will  be  analyzed?  Which  will  not? 

•  What  tools  do  they  plan  to  use? 

•  What  are  the  details  of  their  code  inspection  process  for 
manual  security  analysis? 

•  How  will  they  mitigated  any  discovered  vulnerabilities 
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or  weaknesses? 

COTS  source  code  is  rarely  available  to  the  acquirer  for  inde¬ 
pendent  code  review. 

PMs  should  request  COTS  vendors  provide  Assurance  Cases 
for  their  COTS  products  detailing  both  the  vendor’s  secure  cod¬ 
ing  practices  and  the  results  of  internal  static  code  analysis  or 
third  party  assessment  (e.g.  Common  Criteria  certification). 

In  cases  where  such  information  is  unavailable,  and  there  is 
still  a  desire  to  use  the  COTS  component,  the  PM  should  con¬ 
sider  analyzing  the  executables  using  binary  code  analysis. 

c.  Critical  Design  Review  (CDR) 

1.  Objectives 

The  CDR  is  a  multi-disciplined  technical  review  to  ensure  that 
the  system  under  review  can  proceed  into  system  fabrication, 
demonstration,  and  test,  and  can  meet  the  stated  performance 
requirements  within  cost  (program  budget),  schedule  (program 
schedule),  risk,  and  specific  assurance  requirements  and  con¬ 
straints. 

From  a  software  perspective,  the  CDR  focuses  on  the  com¬ 
pleteness  of  the  detailed  design  and  how  it  supports  functional, 
performance,  and  assurance  requirements. 

2.  Outcomes 

With  respect  to  software  security  and  code  analysis,  the 
CDR  should  document: 

•  Identification  and  use  of  the  selected  static  analysis  tools  for 
source  code  evaluation. 

•  Selection  of  additional  development  tools  and  guidelines  to 
counter  weaknesses  and  vulnerabilities  in  the  system  elements 
and  development  environment(s),  including: 

-Definition  and  selection  of  assurance-specific  static  analyses 
and  assurance-specific  criteria  to  be  examined  during  peer 
reviews  performed  during  implementation. 

-Planning  for  training  for  assurance-unique  static  analysis 
tools  and  peer  reviews. 

The  Assurance  Case  should  also  be  updated  with  relevant 
evidence  as  a  result  of  the  CDR. 

d.  Test  Readiness  Review  (TRR) 

1.  Objectives 

The  TRR  is  a  multi-disciplined  technical  review  to  ensure  that 
the  subsystem  or  system  under  review  is  ready  to  proceed  into 
formal  test.  The  TRR  also  examines  lower-level  test  results,  test 
plans,  test  objectives,  test  methods,  and  procedures  to  verify  the 
traceability  of  planned  tests  to  program  requirements. 

2.  Outcomes 

•Verification  of  static  code  analysis. 

Verification  regarding  static  code  analysis  determines  if 
assurance-specific  static  analyses  and  peer  reviews  of  assur¬ 
ance  criteria  have  been  completed.  Such  verification  includes: 

-Documentation  of  evidence  that  static  analysis  has  been 
performed  (both  source  and  binary)  to  identify  weaknesses  and 
vulnerabilities  such  as  cross-site  scripting,  SQL  injection,  and 
buffer  overruns. 

-Verification  that  another  party  other  than  the  developer  (such 
as  a  peer)  performed  static  analysis  and  peer  review. 

-Documentation  regarding  the  selection  of  any  additional  stat¬ 


ic  analysis  tools  to  identify  or  verify  weaknesses  and  vulnerabili¬ 
ties  in  the  system  elements  and  development  environment(s). 

-For  COTS/GOTS  software  products  with  no  source  code, 
identification  of  industry  tools  and  test  cases  to  be  used  for  the 
testing  of  any  binary  or  machine-executable  files. 

The  Assurance  Case  should  also  be  updated  with  relevant 
evidence  as  a  result  of  the  TRR. 

Even  for  those  with  less  formal  lifecycle  review  processes, 
there  will  generally  be  a  requirements  development  phase,  one 
or  more  design  phases,  and  implementation  and  testing  phases. 

For  some  organizations  there  will  be  operations  and  mainte¬ 
nance  phases  as  well.  The  objectives  and  outcomes  of  the 
lifecycle  touch  points  described  above  for  static  code  analysis 
should  provide  guidance  and  help  set  expectations,  no  matter 
how  formal  or  informal  the  lifecycle  review  process. 

Section  5.  Challenges  to  Automated  Static  Code  Analysis 

There  are  two  challenges  to  the  effective  uses  of  automated 
static  code  analysis. 

a.  Procurement  and  Maintenance  of  Tools 

The  better  static  code  analysis  tools  are  expensive.  However, 
the  best  results  are  obtained  when  multiple  tools  are  used  to 
offset  tool  biases  and  minimize  false  positives  and  false  nega¬ 
tives.  Use  of  multiple  tools  can  quickly  become  cost  prohibitive 
for  a  single  project. 

In  addition,  maintenance  agreements  to  ensure  a  tool  is  up  to 
date  with  respect  to  the  spectrum  of  threats,  weaknesses,  and 
vulnerabilities  add  long  term  costs. 

The  concept  of  “buy  it  once,  use  it  often”  provides  the  most 
bang  for  the  buck.  Pooled  resources  analysis  labs  that  sup¬ 
port  multiple  projects  within  organizations  may  make  the  most 
economic  sense. 

b.  Training 

Static  code  analysis  is  not  for  sissies,  although  it  may  be  for 
CISSPs®  (Certified  Information  System  Security  Professionals). 

This  tongue-in-cheek  statement  belies  the  difficulty  in  using 
static  code  analysis  tools  to  their  best  advantage. 

Chandra,  Chess,  and  Steven  [1  7]  point  out  that  when  static 
code  analysis  tools  are  employed  by  a  trained  team  of  code 
analysts,  false  positives  are  less  of  a  concern;  the  analysts  be¬ 
come  skilled  with  the  tools  very  quickly;  and  greater  overall  audit 
capacity  results. 

In  addition,  in  order  to  determine  the  validity  of  static  code 
analysis  results,  it  is  important  for  PMs  to  understand  the  level 
of  training  that  code  analysts  have  had  with  the  tools  employed 
for  static  code  analysis  as  well  as  their  understanding  of  code 
weaknesses  and  vulnerabilities.  Even  a  good  tool  in  the  hands 
of  a  poorly  trained  or  inexperienced  code  analyst  can  produce 
misleading  results.  A  tool  is  just  a  tool.  How  it  is  used  and  how 
its  results  are  interpreted  are  key  to  useful  and  valid  results. 

Section  6.  Useful  Links 

a.  NIST  Software  Assurance  Metrics  and  Tool  Evaluation 
(SAMATE)  Static  Analysis  Tool  Survey 

The  NIST  SAMATE  project  provides  tables  describing  cur¬ 
rent  static  code  analysis  tools  for  source,  byte,  and  binary  code 
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analysis  <http://samate.nist.gov/>. 

b.  DHS  Build  Security  In  Web  Site 

This  site  contains  a  wealth  of  software  and  information  assur¬ 
ance  information,  including  white  papers  on  static  code  analysis 
tools.  More  information  on  Build  Security  In  can  be  found  at: 
<https://buildsecurityin.us-cert.gov/daisy/bsi/home.html> 

c. CWE 

This  site  provides  a  formal  list  of  software  weakness  types 
created  to: 

•  Serve  as  a  common  language  for  describing  software  security 
weaknesses  in  architecture,  design,  or  code. 

•  Serve  as  a  standard  measuring  stick  for  software  security 
tools  targeting  these  weaknesses. 

•  Provide  a  common  baseline  standard  for  weakness  identification, 
mitigation,  and  prevention  efforts,  <http://cwe.mitre.org/> 

d.  CWE/SANS  Top  25  Most  Dangerous  Software  Errors 

The  2010  CWE/SANS  Top  25  Most  Dangerous  Software  Errors 
is  a  list  of  the  most  widespread  and  critical  programming  errors  that 
can  lead  to  serious  software  vulnerabilities.  They  are  often  easy  to 
find,  and  easy  to  exploit.  They  are  dangerous  because  they  will  fre¬ 
quently  allow  attackers  to  completely  take  over  the  software,  steal 
data,  or  prevent  the  software  from  working  at  all. 

<http://cwe.mitre.org/top25/archive/201 0/201 0_cwe_ 
sans_top25.pdf> 

Section  7.  Summary 

This  paper  has  described  the  scope  of  the  problem  regarding 
vulnerabilities  in  the  code  we  buy,  build,  or  integrate.  As  more 
and  more  COTS  and  open  source  components  are  integrated 
into  our  systems,  the  problem  becomes  ever  more  exacerbated. 
The  paper  has  also  discussed  strategies  for  effective  static 


code  analysis  as  a  means  to  understand  an  manage  supply 
chain  risk,  and  has  described  the  expected  outcomes  regard¬ 
ing  such  analysis  at  appropriate  touch  points  in  the  software 
lifecycle.  Although  the  lifecycle  reviews  described  were  fairly 
formal,  the  activities  associated  with  those  reviews  apply  to 
any  software  development,  integration,  or  maintenance  effort. 

In  addition,  the  paper  has  described  the  Assurance  Case,  the 
repository  for,  among  other  things,  the  empirical  results  of 
static  analysis. 

Lastly,  the  paper  touched  on  challenges  to  automated  static 
code  analysis,  regarding  the  procurement  and  maintenance  of 
tools  and  the  training  required  for  tool  users  in  order  to  facilitate 
accurate  results.  Such  analysis  is  most  effective  when  multiple 
tools  are  used  to  offset  tool  biases,  and  are  employed  by  ana¬ 
lysts  with  proper  training  in  both  tool  use  and  in  security-related 
code  inspection. 

To  be  sure,  there  are  other  means  for  assessing  and  managing 
supply  chain  risk  with  respect  to  software,  but  at  the  bottom  line, 
it  is  all  about  the  code  and  the  vulnerabilities  it  might  contain. 

The  Software  Assurance  Community  Resources  and  Infor¬ 
mation  Clearinghouse  contains  links  to  free  Pocket  Guides  on 
other  aspects  of  supply  chain  risk  management,  including: 

•  Software  Assurance  in  Acquisition  and  Contract  Language 

•  Software  Supply  Chain  Risk  Management  and  Due  Diligence 

•  Key  Practices  for  Mitigating  the  Most  Egregious  Exploitable 
Software  Weaknesses 

•  Software  Security  Testing 

•  Secure  Coding 

Guides  on  other  aspects  of  software  assurance  include: 

•  Requirements  and  Analysis  for  Secure  Software 

•  Architecture  and  Design  Considerations  for  Secure  Software 

•  Software  Assurance  in  Education,  Training  &  Certification 

All  of  these  guides  can  be  found  at: 

<https  J/\ bu  i  Idsecu  rityin.us-cert.gov/swa/pocket_g  u  ide_series.htm  l> 


CALL  FOR  ARTICLES 

If  your  experience  or  research  has  produced  information  that  could  be  useful  to  others, 
Crosstalk  can  get  the  word  out.  We  are  specifically  looking  for  articles  on  software- 
related  topics  to  supplement  upcoming  theme  issues.  Below  is  the  submittal  schedule  for 

three  areas  of  emphasis  we  are  looking  for: 


Resilient  Cyber  Ecosystem 

Sept/Oct  2012  Issue 
Submission  Deadline:  Apr  1 0,  201 2 

Virtualization 

Nov/ Dec  2012  Issue 
Submission  Deadline:  June  1 0,  201 2 


Please  follow  the  Author  Guidelines  for  Crosstalk,  available  on  the  Internet  at 
<www.crosstalkonline.org/submission-guidelines>  We  accept  article  submissions  on 
software-related  topics  at  any  time,  along  with  Letters  to  the  Editor  and  BackTalk.  To  see 
a  list  of  themes  for  upcoming  issues  or  to  learn  more  about  the  types  of  articles  we’re 
looking  for  visit  <www.crosstalkonline.org/theme-calendar> 
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28th  Annual  National  Test  and  Evaluation  Conference 
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19-24  August  2012 
Atlanta,  GA 

<http://www.us-cert.gov/GFIRST> 


IEEE  International  Systems  Conference 
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<http://ieeesyscon.org> 


26th  International  Biometrics  Conference 
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BACKTALK 


There  ie  an 
"I"  in  Security 

Oh  sure,  you  have  received  one.  A  rather  innocuous  e-mail  that 
typically  starts  out  something  like: 


“URGENT  -  HELP  ME  DISTRIBUTE  MY  $15  MIL¬ 
LION  TO  CHARITY 

IN  SUMMARY:  I  have  $15  million  USD  and  I  want  you 
to  assist  me  in  distributing  the  money  to  charity  organiza¬ 
tions.  I  agree  to  reward  you  with  10%  of  the  money  for 
your  assistance,  kindness,  and  participation  in  this  Godly 
project.  This  e-mail  might  come  to  you  as  a  surprise  and 
the  temptation  to  ignore  it  as  unserious  could  come  into 
your  mind,  but  please  consider  it  a  divine  wish  and  accept 
it  with  a  deep  sense  of  humility.” 

I  mean,  after  all,  you  are  a  savvy  Internet  user  and  you  just 
KNOW  that  nobody  is  going  to  give  you  1 0%  of  $1 5  million, 
right?  I  teach  Enterprise  Security  here  at  Stephen  F.  Austin  State 
University.  Last  month,  right  before  class,  I  received  the  following 
e-mail  (copied  verbatim): 

“How  are  you  ?  I  do  hope  that  you  receive  this  e-mail  in 
good  health.  I  am  presently  in  Madrid,  Spain  to  be  with  my 
ill  cousin  (Chloe).  She  is  suffering  from  a  critical  medical 
condition  and  must  undergo  surgery  to  save  her  life.  I  am 
deeply  sorry  for  not  writing  or  calling  you  before  leaving, 
the  news  of  her  illness  arrived  to  me  as  an  emergency  and 
that  she  needs  family  support  to  keep  her  going.  I  hope 
you  understand  my  plight  and  pardon  me. 

I  want  to  transfer  her  back  home  to  have  the  surgery 
implemented  there  because  surgery  is  very  expensive  here. 

I  am  wondering  if  you  can  be  of  any  assistance  to  me.  I 
need  about  ($2,500)  to  make  the  necessary  arrangement; 

I  traveled  with  little  money  due  to  the  short  time  I  had  to 
prepare  for  this  trip  and  never  expected  things  to  be  the 
way  it  is  right  now.  I  will  surely  pay  you  back  once  I  get 
back  home.  I  need  to  get  her  home  ASAP  because  she  is 
going  through  a  lot  of  pain  at  the  moment  and  the  doctor 
have  advised  it  necessary  that  the  tumor  is  operated  on 
soon  to  avoid  anything  from  going  wrong.  I  will  reimburse 
you  at  my  return. 

Anticipating  your  reply  at  the  earliest  to  my  request! 

Thank  you  for  all  of  your  assistance." 

For  those  of  you  who  have  not  been  spammed  this  way,  it 
appeared  to  come  from  a  Facebook  friend.  Seems  my  friend’s 
Facebook  page  had  been  compromised-he  had  responded  to 
the  following  e-mail: 

“HELLO,  your  Facebook  account  has  been  suspended 
due  to  suspected  compromise.  Please  reset  your  account 
password  with  the  link  below  to  reactivate  your  account.” 


My  friend’s  compromised  account  let  the  spammer  target  all  of 
his  friends  (using  spoofed  e-mail)  trying  to  get  some  money  from 
them.  The  fun  part  for  me  was  sharing  this  with  my  class,  and, 
over  the  space  of  a  full  week,  playing  this  scammer  along.  First  I 
offered  to  send  the  money  direct  to  his  wife  (by  the  way,  I  knew 
he  was  not  married).  After  a  return  e-mail  explaining  that  ONLY 
a  money  order  to  Spain  would  suffice,  I  then  offered  to  send  the 
money  as  a  direct  deposit  to  his  bank  account.  Over  the  next 
week,  his  cousin  Chloe  mysteriously  progressed  from  a  tumor  to 
cancer,  then  to  emergency  abdominal  surgery.  I  was  expecting  ei¬ 
ther  malaria  or  the  Black  Plague  next.  I  sent  him  on  a  wild  goose 
chase  towards  the  end,  saying  the  money  order  was  returned  due 
to  a  wrong  address.  After  about  five  e-mail  exchanges,  I  finally 
told  the  scammer  than  he/she  had  provided  entertainment  and 
education  for  my  security  class.  The  spammer,  in  turn,  had  the 
class  to  say  “good  luck”  on  the  final  e-mail. 

Seriously,  how  many  scams  do  we  get  via  e-mail  and  the  Inter¬ 
net?  I  am  not  really  the  1 ,000,000th  visitor  to  the  web  site.  I  have 
not  won  a  free  iPad  for  participating  in  a  survey.  There  is  no  magic 
sweepstakes  that  you  are  automatically  entered  in  based  on  hav¬ 
ing  an  e-mail  account.  The  IRS  is  not  trying  to  send  me  a  refund 
using  an  .aol  address.  FedEx  did  not  send  an  executable  file  to 
me  explaining  why  they  did  not  complete  my  delivery.  The  Better 
Business  Bureau  is  not  trying  to  redirect  me  to  a  page  to  explain 
a  “suspicious  complaint”  against  me. 

Yet,  every  day  somebody  “clicks  before  thinking.”  We  often  for¬ 
get  that  our  e-mail  address  and  our  Internet  connections  serve  as 
a  huge  “ATTACK  ME  HERE”  target  to  those  with  no  scruples.  No 
matter  how  good  your  firewall,  spam  filter,  or  antivirus  software  is, 
nothing  in  the  world  that  will  protect  you  from  momentary  stupidity 
on  the  part  of  the  user.  You  need  to  have  frequent  education  and 
training  on  how  to  keep  yourself  safe.  There  are  SO  many  ways 
that  security  can  be  compromised  by  literally  inviting  malware  or 
viruses  onto  your  computer.  Do  not  think  that  a  quick,  “I  will  take 
the  online  test,  and  get  an  80%  without  studying,”  is  enough.  You 
have  to  be  prepared  and  educated  every  time  you  sit  down  at  a 
computer.  You  have  to  think.  Indeed,  you  might  be  the  “Weakest 
Link”.  You  do  not  need  an  unsecured  USB  drive  to  compromise 
security.  You  have  to  think  “E-mail  and  Internet  Security”  ALL  the 
time,  no  matter  where  you  are  . . . 

...  he  says,  as  he  sits  with  his  MacBook  at  Starbucks,  sipping 
on  a  venti  coffee  with  extra  cream,  answering  e-mails,  paying 
off  a  few  bills,  and  sending  this  column  off  to  the  wonderful  and 
humble  staff  at  crosstalk  . . . 

...  using  an  open,  unencrypted,  unsecure  Internet  connection 
with  at  least  1 0  people  nearby  on  their  own  computers,  potentially 
monitoring  and  copying  every  keystroke  and  piece  of  data  going 
into  and  coming  out  of  my  computer. 

Go  figure.  It  is  easier  to  preach  than  to  actually  follow  my  own 
good  advice. 

But  that  is  another  column. 


David  A.  Cook  Ph.D. 

Stephen  F.  Austin  State  University 

E-mail:  cookda@sfasu.edu 
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Crosstalk  thanks  the 
above  organizations  for 
providing  their  support. 
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Software  is  essential  to  enabling  the 
nation’s  critical  infrastructure. 

To  ensure  the  integrity  of  that  infrastructure,  the 
software  that  controls  and  operates  it  must  be 
secure  and  resilient. 

Software  Assurance  Community  Resources  and 
Information  Clearinghouse  provides  corroboratively 
developed  resources.  Learn  more  about  relevant 
programs  and  how  you  can  become  involved. 


Security  must  be  “built-in”  and 
supported  throughout  the  lifecycle. 

Visit  https://buildsecurityin.us-cert.gov  to  learn 
about  the  practices  for  developing  and 
delivering  software  to  provide  the  requisite 
assurance.  Sign  up  to  become  a  free 
subscriber  and  receive  notices  of  updates. 

The  Department  of  Homeland  Security 
provides  the  public-private  collaboration 
framework  for  shifting  the  paradigm  to 
software  assurance. 
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